DEV Community: Adam Lewis

Compiling Android in Jenkins In Docker (A bitter victory)

Adam Lewis — Sun, 04 Feb 2024 16:40:48 +0000

Part three of an N part series: Successfully building an Android app inside of a docker container, controlled by Jenkins, running in inside of a docker container, on a NAS - but at a cost... Covers the advanced set up of a Jenkins server on a QNAP NAS & getting a build to run

Step One - Accessing docker in Jenkins

To use docker agents in Jenkins we're going to need to expose docker on our host to the docker runtime in our container, so it can create & control other containers as siblings. In its simplest form, this is quite easy. First we need to SSH into our NAS & write a new Dockerfile:

FROM jenkins/jenkins:lts-jdk17

USER root
# Ensure we're using latest available packages, install docker & then remove the cache to ensure a lean image
RUN apt-get -yqq update && \
    apt-get -yqq install docker.io && \
    apt-get clean

then followed by a docker build and a docker run to test it:

docker build -t tmp --progress=plain .
docker run -v /var/run/docker.sock:/var/run/docker.sock -it --rm --entrypoint /bin/bash tmp

We can see everything is working as expected! 🎉🎉

root@c66bce970068:/# docker image ls
REPOSITORY        TAG         IMAGE ID       CREATED        SIZE
tmp            latest      723acf6a32d6   10 seconds ago   872MB

Great, we're done, right? Unfortunately, no.

Step Two - No root please

While it's great that Jenkins can access our docker socket & control docker in the host - the eagle eyed amongst you may notice we are running as the root user, we forgot to switch back to the default jenkins user in our Dockerfile:

FROM jenkins/jenkins:lts-jdk17

USER root
# Ensure we're using latest available packages, install docker & then remove the cache to ensure a lean image
RUN apt-get -yqq update && \
    apt-get -yqq install docker.io && \
    apt-get clean

# Switch back to default jenkins user so we're not running as root
USER jenkins

But now if we try to access docker within our container we get the an error:

Got permission denied while trying to connect to the Docker daemon socket

This happens because when you use a bind mount in docker, it maintains the permissions of the host's file system when injecting it to the container's - as far as the Jenkins container is concerned, the jenkins user isn't permitted to access the socket so we're blocked from using docker! So how can we fix this? Well, first, let's take a look at our current permissions to check out the groups:

[~] # ls -la /var/run/docker.sock
srw-rw---- 1 admin administrators 0 2024-01-26 00:24 /var/run/docker.sock=

Ah. Well, we don't want to give our Jenkins container full rights as part of the administrators group - after all, this is still my home NAS & I don't want to expose a backdoor! 😨 So let's come at this differently: We'll create a new group, give it rights to use the docker socket & then assign that group to our admin user on the host & the jenkins user in the container! First, creating our new group & assigning it to the admin user is simple enough:

addgroup admin jenkins

And then we can modify our permissions:

getent group jenkins # Note the group id
chgrp 1000 /var/run/docker.sock # Use the group id as needed
docker ps # check everything is still working

Great, new group created, admin user configured to use it - last step, Jenkins:

FROM jenkins/jenkins:lts-jdk17

USER root
# Ensure we're using latest available packages, install docker & then remove the cache to ensure a lean image
RUN apt-get -yqq update && \
    apt-get -yqq install docker.io && \
    apt-get clean

# Force our internal docker group to have the same GID as our external jenkins user
ARG DOCKER_GROUP_ID
RUN groupmod -g $DOCKER_GROUP_ID docker && gpasswd -a jenkins docker

# Switch back to default jenkins user so we're not running as root
USER jenkins

Which we must build with a modified command now, to pass the required group info:

docker build --build-arg DOCKER_GROUP_ID=`getent group jenkins | cut -d: -f3` -t tmp --progress=plain .

Start up a container again, test docker ps & yes! We're in business 🎉🎉🎉🎉
Now let's try out our real thing in Jenkins... We'll start a container using a command instead of the UI to configure everything we want:

docker run -v /var/run/docker.sock:/var/run/docker.sock -v jenkins_home:/var/jenkins_home -p 35035:8080 -it --rm tmp

And update our Jenkinsfile to test out the connection inside of the pipeline:

pipeline {
    agent any
    stages {
        stage('Example') {
            steps {
                echo 'Hello World'
                sh 'docker run alpine:latest echo Goodbye world'
            }
        }
    }
}

And isn't it just magic?

Step Three - compiling the application

To support docker agents, we're going to first need to install some plugins on our server:

And we can quickly rewrite our Jenkinsfile to use the new syntax:

pipeline {
    agent {
        docker { image 'alpine:latest' }
    }
    stages {
        stage('Example') {
            steps {
                sh 'echo Hello world'
            }
        }
    }
}

But obviously, we're going to need something that can compile Android, not a basic Alpine Linux container! For this, I decided to use MobileDevOps android-sdk-image as it had everything I would need nicely bundled up already for me. No need to reinvent the wheel after all! Before we get started though, our Jenkins server is going to need some more config first - we can only compile our application if we have a keystore to sign it.

For this, I simply uploaded the debug keystore from my laptop. For Windows users this can usually be found at: C:\Users[username].android\debug.keystore and for Mac/Linux users: ~/.android/debug.keystore.
With the keystore in place, we can update our build.gradle.kts (don't worry about the passwords, they're default debug ones!):

signingConfigs {
    create("debug_jenkins") {
        storeFile = file ("${project.rootDir}/keystore.jks")
        keyAlias = "androiddebugkey"
        keyPassword = "android"
        storePassword = "android"
    }
}

buildTypes {
        debug {
            if (System.getenv("IS_JENKINS") != null) {
                signingConfig = signingConfigs.getByName("debug_jenkins")
            }
        }
    }

And finally... Our Jenkinsfile:

pipeline {
    agent {
        docker { image 'mobiledevops/android-sdk-image:33.0.2' }
    }
    stages {
        stage('Example') {
            environment {
                KEYSTORE_FILE = credentials('android_debug_keystore')
            }
            steps {
                withEnv(["IS_JENKINS=YES"]) {
                    sh "cp -f \"${KEYSTORE_FILE}\" \"keystore.jks\""
                    // Useful for debugging keys
                    // sh './gradlew signingReport'
                    // Do the build!
                    sh './gradlew clean assembleDebug assembleDebugUnitTest assembleDebugAndroidTest'
                }
            }
        }
    }
    post {
        always {
            archiveArtifacts artifacts: 'kotlin_app/app/build/outputs/**/*.apk', fingerprint: true
            sh 'rm -f "kotlin_app/keystore.jks'
        }
    }
}

And that's it... Click build in Jenkins, sit back and watch the magic happen:

Conclusion

So where's the sadness/cost I mentioned at the start of this article? We set out to do everything we wanted to when we started this project and we've even made it fully flexible. We have:

Jenkins running in docker
Jenkins spinning up a new container to build our application
And the application compiled All in a documented & committable format! Well, the catch is do you remember this line from earlier?

sh 'docker run alpine:latest echo Goodbye world'

Unfortunately, our docker set up is not configured to run rootless, which means if I were an evil-me, I could run something like this:

sh 'docker run -v /:/host alpine:latest rm -rf /host/*'

And uh. That would be bad. Goodbye media collection. Our Jenkins would happily inform our host to mount our root directory, the docker user will happily run as a root user & we will destroy everything.

But at the end of the day - that's okay - at least for me for now. Why? Because:

I am only going to spin up this server when I need it
I am only ever going to point it at private repositories with private build files stored within them

Maybe one day I'll write a part four, discovering how to make my QNAP run docker rootless to close this hole. Maybe one day I'll just accept that I should use a cloud based solution instead. Or maybe one day I'll set up a new server that I don't care about it it gets exploited.

But until that day... I'll call it goal achieved

Compiling Android In Jenkins In Docker (nearly!)

Adam Lewis — Tue, 30 Jan 2024 23:09:46 +0000

Part two of an N part series: My first steps into trying to compile an Android app via Jenkins in docker. Covers the initial set up of a Jenkins server on a QNAP NAS in docker and the realisation that this project can be so much more...

Step One: Creating and connecting the server to GitHub

To begin our journey, I knew that first I would need to head on over to the Docker hub and to find the official Jenkins image: https://hub.docker.com/r/jenkins/jenkins

This should have everything we need to set up some pipelines on my QNAP NAS in Container Station - and even better! There's a tag with the JDK already installed - this might be perfect for building an Android app no? (Spoiler, it wasn't!)

So let's get the jenkins/jenkins:lts-jdk17 image pulled locally to our NAS...

Okay, so far so good, now let's create a new volume for our Jenkins server's future home directory, so we don't lose any data between container restarts:

And finally, with the basics done, we can move on to the good stuff: Creating a container that will have a running server inside of it! First, let's tell Container Station that we want to use the image we just downloaded:

And then let's configure our container with a name & ensure that port 8080 is exposed (but not 50000 as we're not interested in allowing any Jenkins workers to connect to our main server in this setup)

And thinking of stuff we probably don't need... Full access to our RAM is likely overkill too - this is still a media server too after all - so let's try limiting it to 1GB for now to see how that handles the load:

And for the last step, let's configure the home directory to use that volume that we created earlier:

Annnnnnnnd bingo!

Once the initial setup wizard is taken care of, it's a simple case of creating our first pipeline! Let's just add the SSH key to clone my repo annnnnd oh. Okay, well, problems are normal and to be expected:

Let's see, Google, StackExchange - aha! Got you!

A bit of SSH magic later via a terminal inside of our container et voilà!

Let's try running against our script (stored in a Jenkinsfile inside of git of course!)...

pipeline {
    agent any
    stages {
        stage('Example') {
            steps {
                echo 'Hello World'
                sh './gradlew clean build'
            }
        }
    }
}

And we are in business!

But oh. I should've seen this coming... Jenkins may have the JDK but it definitely doesn't have the Android SDK... So the build fails...

Well, this could be as simple as writing a new Dockerfile... But let's face it - this tutorial is much closer to what would actually be useful.

I started this project with a goal, but why should I build a one trick pony? A Jenkins server that can only build my Android apps? What if I write some TypeScript? .NET? ? Will I always restart my Jenkins server/make one big, complex, Dockerfile/image?

No. We can do better than that and should do better than that:

Jenkins server running in a container - Done already ✔
Builds running in ephemeral Jenkins container agents defined by Dockerfiles/images - I've done this before ✔
Container with docker installed managing docker on the host - I've done this before too ✔

The result of this should be:

A single Dockerfile that defines how to create my Jenkins server, that can be stored in git!
A Dockerfile/Image reference per project, that can contain all of the tooling I need, stored in git!

Which when I consider the origins of this little project I think I'm sold! My own build system, almost entirely defined as & reproducible as code

Until part three

Setting up Android CI/CD, the intro - Insurance for a rainy day

Adam Lewis — Sat, 27 Jan 2024 23:08:56 +0000

Part one of an N part series: The motivation behind trying to build my own CI system & why now. (Part two)

Three and a half years have gone by since I wrote my first post here on dev.to: Why I wrote a Password Manager and what I've learned and a lot has changed since then. I've learned new skills, met new people and even moved to a new country! So I can even say that I have learned not only new programming languages but a new spoken one too!

Yet during all of this time and through all of these changes, one thing has remained consistent and stayed the same: my laptop. Nearly 8.5 years old now, my machine is definitely starting to feel the effects of Moore's Law however...

But still this machine just keeps on going. It keeps processing and compiling and taking on whatever little software projects I throw at it all in stride without so much as a single complaint (Ignoring one dead & replaced SSD!)

That was until recently however when the power jack stopped working and I thought is this it, the end?.. Will I at last have to replace you and say farewell?

Well I can happily write, on the afflicted laptop, that thanks to a bit of luck & some DIY repairs, we're going to stay together for a little while longer!

That is at least until Microsoft ends support for Windows 10 in 2025... By which point I should accept that our time together is over & that my trusty machine will probably become a file server/backup machine or something else...

Which got me thinking: what am I going to do when the day eventually does come that we say farewell to one another? When I finally buy myself a shiny new machine to catch up with the latest tech?

One thing I know for certain is that I don't want to create more pain than is absolutely necessary recreating my environment... Maintaining/deciphering READMEs & the toolchains they describe sucks, and these last few years I've tried to combat this in both my professional & personal work by leaning heavily into the concept of "dev-env as code" thanks to the ability to run Visual Studio code connected to a docker container/stack of containers: example...

And honestly? I've found this approach very useful... I can destroy/swap between projects easily - so why not try to learn and push ourselves a little further?

I have an old Android app & an old laptop both from that original article 3.5 years ago, but today I have stronger docker & jenkins knowledge + a NAS server that can run containers...

Let's build ourselves a dockerised CI/CD system

Part two coming soon...

Dr. Strangelove or: How I Learned to Stop Worrying and Love the Tests

Adam Lewis — Fri, 27 Aug 2021 22:38:27 +0000

Recently I've been spending a lot of time thinking about automated tests.

Why do we write them? Well the benefits are obvious:

They prove your new code works
They continue to prove your new code is still working, even as it ages and drifts into obsoletion...
They act as documentation that must be updated, providing valuable insights to the next developer who needs to maintain your code

So then why do so many companies struggle to establish coherent strategies given these benefits? Why are there so many instances of "we tried it, but it didn't really work, so we're trying this instead"?

Well, is it any surprise really?
How can you talk with both your fellow devs and non-devs about the different approaches without getting into a quagmire of confusion?

Unit tests, Integration tests, Regression Tests, Feature Tests, White Box, Black Box and more...
Given, When, Then. Arrange, Act, Assert.

And the always famous "How big is a unit in a unit test?"

This post is an attempt of trying to put into words the things I've learned and the perspective I've gained to cut through the mess and put all of the confusion into a single framework.
All in the format of a conversation with myself from the past if you will permit... ;)

1) Drop the unit tests and integration tests

What?
I know, I know. Advising you drop tests - crazy right? But hold on!

My advice is not to stop writing the tests you already are, but to drop the terms and baggage that comes with their connotations.
Stop thinking about unit tests as things that test your classes.
Stop thinking of integration tests as things that test your services.

Instead, think about identifying what it is you want to test and talk in those terms. Don't write unit tests and integration tests, write:

Code level tests
Build level tests
Subsystem level tests
System level tests

And then treat this test entity as a black box. What this means is for:

A class you do not write tests that rely on private state/asserting certain paths of logic are followed
The build of your service you do not write tests that will assert the flow through certain classes
A subsystem you do not test the interactions of/state of the individual services that make the sub-system
The whole system you do not test the interactions of/state of subsystems/services

Phrased another way, we only want to write our tests based on four things:

What we input into the test entity
What the test entity returns
What the test entity outputs into its dependencies
What the test entity can receive as an input from its dependencies

By doing this, you'll be able to drop the shackles of unit tests and integration tests and start talking about these test levels as gates to the next stage in your CI/CD train!

Code level tests pass? We can create the build!
Build level tests pass in an emulated deployment environment? We can deploy it into an environment!
Subsystem/System level tests pass in the deployed environment? Our environment is healthy - we can promote it to the next environment!
Subsystem/System level tests pass in the deployed environment? Our environment is healthy - we can promote it to the next environment!
Subsystem/System level tests pass in the deployed environment? Our environment is healthy - we can promote it to the next environment!
To however many you want...

2) Embrace that you can test four things

No matter the size of your test entity, you can always test four things related to that entity:

Quality (An aspect of the entity-under-test that isn't directly tested but can be analysed by metrics)
Features (Something the entity-under-test does entirely within itself)
Integrations (Something that the entity-under-test does by interacting with other similarly sized entities)
End-to-end (Testing that complex multi-step use cases generate the result that is expected, but strictly only when the state is contained within the entity-under-test)

Okay? What does this mean? Can you give examples?
Sure:

Code level tests, such as testing a class/react component
-- Quality - this is stuff like running a code linter to check the code is in line with standards
-- Features - this is the equivalent of testing a sorting algorithm, where all logic is contained in the class
-- Integrations - this is the equivalent of testing that your class interacts with other classes correctly
-- E2E - if you're writing this kind of test here then your code is probably badly written to be honest. But there are some valid use cases, such as testing an object that implements the Builder pattern so it still applies!
Build level tests, such as testing a NodeJS docker container
-- Quality - this is stuff like checking the image does not contain your dev dependencies
-- Features - could be something like testing that a particular element is visible on a webpage
-- Integrations - could be something like testing that given a POST, a row is created in a database
-- E2E - could be something like uploading a png and then downloading a watermarked version from your service, where the image is kept in the container's local file system
Subsystem level tests, such as testing your new NodeJs image deployed with the database it uses
-- Quality - this is stuff like how is the performance? What are the error rates like?
-- Features - could be something like testing that "get product info" returns JSON (but not testing that it used certain tables in your database! It's a black box!)
-- Integrations - could be something like testing that your subsystem fetches the stock of a product from another subsystem
-- E2E - testing things like we can create product followed by get product
System level tests, such as testing a social media site
-- Quality - similar to subsystem level tests, this is stuff like how is the performance? What are the error rates like?
-- Features - could be something like testing that the search feature has auto-suggest
-- Integrations - I lied earlier. You can't actually test this one! More on this soon...
-- E2E - testing things like upload picture, rename picture & tag friends

Alright, but why no integration tests at the system level?

Wait. First recognise that you can now talk about the different aspects of an entity-under-test with a fellow developer. That you have strong clear definitions to back them up. Awesome right?

Fine, I can see that, but why no...

Okay okay! I get it already. I understand. Why no system level integration tests... Well it's simple really (but can require a certain amount of perspective shifting to see it) - the system does not interact with anything of a similar size.
It is made up of subsystems that interact with each other, including any third party ones you might use!

Eh?

By integrating your own sub-system with another third party one, that third party system has become a part of your system.
Without it, you don't function.

I'm not sure?..

Alright, try thinking of it this way.
Let's say you wrote a system that upon ordering food, it posts to DevTo.
You write some Integration tests at the build or subsystem level to check that it interacts with a mock DevTo service as expected - great!
We still have to use the real DevTo though and check that things continue to work when we're not using the mock.
Well, you can define your food sub-system & DevTo as a sub-system itself! That is, DevTo can be thought of as part of the internal state in your entity-under-test. It's no longer two entities talking to each other but rather two entities thought of as one.

By this absorbing aspect, anything that's used by your system becomes part of your system.

Summary

So that's it! Automated tests can be described in generic terms. Provided you pass all of the tests you've written under the four catagories, you can confidently move your entity-under-test to the next stage. You can move from a class in the source to a build. From a build in a per-build environment to a per sub-system environment. Per sub-system to the whole system. Rinse and repeat as many times as you need to move to the production environment!

Now comes the hard part. Establishing common understanding with my peers based on this framework...

Given When Then

Adam Lewis — Sun, 20 Dec 2020 17:31:42 +0000

Today I'm happy to announce that I have released my first public Nuget package today! And in true Christmas fashion, I'd like to share it with you dear reader as a potential way to improve the quality of your testing code :)

nuget
Source

Motivation

Writing tests under the "Given When Then" approach is something I've come to appreciate these last few years for its ability to produce clear and easy to follow test cases. This style of test writing is covered extensively elsewhere, but speaking generally the base concept is:

Given an initial state
When something happens
Then the result is/these things happen

Where I work there is a heavy focus on making test names as close to plain English as possible. The benefits of this are two fold:
1) Code is easier to maintain as a developer
2) Code is easier for less technical testers to evaluate whether there is sufficient coverage

But when writing tests however I noticed that I was starting to feel minor annoyances with the quality of code being produced. Naming could quickly get out of hand when trying to follow the given-when-then pattern:

public void Given_the_database_is_empty_when_searching_for_open_orders_then_it_returns_no_orders_found()
{
    ...
}

Spurred on by this problem, I did what any good Software Engineer should - apply some creative thinking. GivenWhenThen is the result and it aims to make writing tests in this style as simple as:

[TestCaseSource(nameof(TestCases))]
public void TestThat(
    GivenWhenThenTestCase toRun)
{
    toRun.RunTestCase();
}

public static IEnumerable<GivenWhenThenTestCaseData> TestCases
{
    get
    {
        yield return GivenWhenThen.Create(
            Given.UsernameValidationFails,
            When.FredTriesToLogOn,
            Then.LogOnFailsBecauseTheUserIsNotValid);
        yield return GivenWhenThen.Create(
            Given.NoUsersExist,
            When.FredTriesToLogOn,
            Then.LogOnFailsBecauseTheUserDidNotExist);
        yield return GivenWhenThen.Create(
            Given.FredExists,
            When.FredTriesToLogOn,
            Then.LogOnSucceeds);
    }
}

Which to my eyes reads beautifully and renders wonderfully in a test runner too:

Thoughts?

More detail

A True Single Page Application

Adam Lewis — Wed, 07 Oct 2020 22:36:35 +0000

Today I wrote a Single Page application in Vanilla Javascript that can literally be printed onto a single page of paper:

Thanks to the magic of IttyBitty and JS/CSS minifiers I proudly present the most single-page single-page app that I'm aware of: Aster Plotter!

Based on source this tool lets you easily represent exactly how far you are in total, with differently weighted components added together to give a true idea of progress!

Personally I find this very useful for presenting Sprint progress ;)

Why I wrote a Password Manager and what I've learned

Adam Lewis — Sat, 27 Jun 2020 16:19:30 +0000

Longtime reader, first time writer :)

Some years ago as a recent graduate of university, I was working for Citrix in my first serious position of employment, updating the installers for their XenClient XT product (now OpenXT). Smart phones were beginning to truly reach their stride in how useful/powerful they could be. Advertisers were toying with interactive ads via the use of NFC & QR codes. And a recent move from academic pursuits into working on a security based project got me thinking...

"I wonder what it would take to log in with a QR code?"

I scratched down some ideas, looked into it a little from a feasability perspective and then quickly forgot about it. I had a job, other things to do/not much time and a lack of confidence in my ability to build what I'd need. Aside from sitting in my list of "ideas I once had" and occasionally reminding me of that time I thought "It would be cool if..." the project was on ice for a few years.

Then came a period of unexpected unemployment. For the first time in a long time I had a large window of time with no plans on how to use it. I found myself once again looking at my list, but this time with the idea of shortening it instead of lengthening it.

Out of all of the terrible/good ideas in the list the QR logon app caught my imagination again. How many times had I been in a hostel over the last few years using one of their computers lamenting the fact I had no good password management solution?

By the time I had my next professional project lined up, I had used the experience gained over the previous years to build a working prototype - an idea made reality, ready to use whenever I wanted!

The next goal was to refine until I felt ready to share my idea with the world. This part was probably the most difficult! Finding a balance between wanting your release to be perfect & knowing which problems actually don't need to be fixed is no easy task. Nor is balancing professional and personal projects time wise!

But today as I write this, QRGoPass is live. 7 people in the world are using my app and I couldn't be happier with this little success.

TL;DR:

Keep a list of your ideas - it's great for nostalgia and you never know when you might find yourself with the time and skill improvements needed to implement one!
Be persistent - small progress is still progress, give it time and you'll eventually succeed
Target a minimal viable release - learn how to say "good is good enough"