Android and Jenkins: What Is the Limit? Part Two.

Now, I’ve dabbled with memory-constrained devices before, and I know a Jenkins controller can work with a measly 1GB of RAM. I have no clue how much of that sweet memory pie the Android system will serve up to Termux, or how much Termux will pass along to the JVM, but hey, let’s roll the dice! When I SSH in from my PC, here’s what I see:

Looks like we’re sitting on a cozy 3.6GB of RAM, which should be just about enough to wrangle a Jenkins controller into submission. Let’s fire it up using the trusty jenkins.war file, the lazy dev’s best friend!
But first, a quick pit stop to grab the latest LTS version of Jenkins.
The official documentation says it’s 2.504.1 at the time of writing, but, you know, details.

Now, with our newfound love for curl, let’s snag that jenkins.war file:

The next step is to grab a newer version of Java, as things have changed quite a lot since our first experiment!

Installing fonts with your JDK may feel like inviting a violinist to a rock concert — but Jenkins insists. Without them, it simply refuses to show up.

With the file safely in our grasp, it’s showtime! Let’s unleash Jenkins upon this unsuspecting Android device:

The familiar lines start flowing:

The web page is also looking familiar, except for the path where the password is stored:

All seems well, until Jenkins throws a tantrum about the absence of a /tmp dir:

Jenkins throws a fit when it can’t find /tmp. We’ll avoid the drama by setting $PREFIX/tmp as its temp playground later on.

Minor hiccup aside, the installation chugs along smoothly, and the default plugins find their cozy little corner.

The journey nears its end, punctuated by the customary security warning about the use of the built-in node.

Nothing to do with Termux, but we’ll iron out the kinks later.

We’ll want to show off a bit later, so let’s get the Platform Labeler plugin ready. Go to "Manage Jenkins" > "Plugins" > "Available Plugins", search for it, check the box, and select the blue "Install" button. Yes, it’s that easy.

Now go back to your console, and Ctrl+C so you firmly ask Jenkins to shut down.

Quite the milestone, huh?
We’ve proven that we can kickstart a Jenkins controller using Termux on an Android device.
But hold onto your hats, folks! We’re not done just yet.
Next up, we’ll ensure this Jenkins controller can strut its stuff as a service, and then, we’ll tweak it to kick off automatically at boot time.

Now, we could just let Jenkins lurk in the shadows, but where’s the fun in that? What if Android decides to play the ultimate prank and terminate Termux, or the device throws a fit and decides to reboot? We’d be stuck manually resurrecting Jenkins every single time, and that’s just not the cricket we signed up for.
So, let’s give Jenkins a promotion, shall we? Time to turn it into a proper service!

The standard Jenkins installation migrated from init to systemd a while back. Unfortunately, Termux isn’t in on the systemd party, so we’ll have to make do with the tools it offers.
Enter termux-services, a handy collection of scripts for service wrangling.
Instead of cluttering up ~/.bashrc or ~/.bash_profile, we can now start and stop services with a flick of the wrist, thanks to termux-services.
There’s already a smorgasbord of existing services ready to roll, and just like with systemd, there’s nothing stopping us from crafting a bespoke service for our beloved Jenkins.

To get termux-services up and running, execute:

Then, give Termux a gentle nudge so that the service-daemon springs to life.

Next up, to unleash the power of a service, fire off:

If you’re in the mood for a one-off joyride, a simple:

will suffice.
And when it’s time to hit the brakes, just tap into your inner traffic cop with:

Or, if you’re feeling particularly ruthless, disable it altogether:

A service is like a restless spirit shackled to this mortal realm if $PREFIX/var/service/<service>/down exists, so the sv-enable and sv-disable scripts play a little game of touch-and-go with this file.

Under the hood, termux-services taps into the mighty runit to reign in the chaos of services.
You’ll find a treasure trove of example scripts on the runit website.
If you spot a script you fancy, or if you’re feeling particularly creative, just follow these steps:

Then, tuck your run script snugly into $PREFIX/var/service/<PKG>/run, making sure it’s ready for its close-up.

You can then run

to breathe life into your creation.

The log files for these services bask in the limelight at $PREFIX/var/log/sv/<PKG>/, with the star of the show bearing the name "current".

Now that we’ve mastered the art of creating and deploying services with Termux, let’s give our Jenkins controller a promotion.
First up, we need to whip up a script to kickstart Jenkins as a service. Let’s call it run and tuck it snugly into the $PREFIX/var/service/jenkins/ directory.

With our script ready, let’s test if Jenkins plays nice as a service:

Time to peek under the hood and see if Jenkins is revving up by checking the logs:

Voilà! Standard Jenkins logs, just like we’re accustomed to seeing on a run-of-the-mill server.

With Jenkins now up and about, you can access it at the port 8080 on your trusty Android device.

We’ve hit two major milestones:

Pretty cool, right?
But what if the device decides to throw a curveball and reboots? I know, this whole experiment is just a tech whimsy, but let’s push the boundaries and see how far we can take it. Frankly, even if I’m just treating this as a fun experiment, I’d rather not deal with the hassle of launching Termux every time I reboot the device.
So what’s the logical next step? Adding the Jenkins service to the roster of auto-starting services when the device boots up.

Remember when we conjured up an SSH key pair for our Android device? Well, we’re going to do it again for the agent. Time to add the public key to the ~/.ssh/authorized_keys file on the Android device.
Get ready to unleash some command-line magic:

To add the generated public key to the authorized keys file, we can use the cat command to append the public key to the ~/.ssh/authorized_keys file. Here’s how we can do it:

This command will add the contents of the id_rsa.pub file (which is our public key) to the authorized_keys file. If the authorized_keys file doesn’t exist, no worries – it’ll be conjured into existence for us.

Now, before we get too carried away with our newfound access, let’s ensure our digital fortress is properly fortified. The ~/.ssh directory should flaunt permissions worthy of a royal decree: 700 (drwx------). Meanwhile, the authorized_keys file should be wrapped in the impenetrable cloak of 600 (-rw-------) permissions.

If you’re feeling particularly wizardly, you can set these permissions using the chmod command:

Let’s infuse this with a touch of levity:

If you’re still getting the password runaround when attempting to connect, there’s a chance our SSH server isn’t keen on our public key party trick.
Time to play detective! Navigate to the $PREFIX/etc/ssh/sshd_config file and make sure it hasn’t ghosted us. Look for a line that reads like the magic incantation we need:

If you’ve been tinkering with the sshd_config file, remember to give the SSH service a friendly nudge to let it know about the changes. Now that we’ve got the key to the kingdom, it’s time to set up a VIP pass for Jenkins.

Take a stroll over to the Jenkins controller and swing by "Manage Jenkins" > "Credentials" > "System". Next, hover over "Global credentials (unrestricted)" like a champ, select the down arrow, and select "Add Credentials".

Now, choose "SSH Username with private key" as the type of credential, and let’s fill in the details:

Select the white on blue "Create" button, and voilà! You should now be the proud owner of a brand spanking new credential named "jenkins-agent". Jenkins is now armed with this secret handshake to chat with the Android device (which, let’s be honest, is basically chatting with itself).

Alright, back in the driver’s seat at "Manage Jenkins", let’s give that shiny blue "Set up agent" button a good ol' click and dive into the adventure!

Time to give our agent a name – I went with Myself because, well, it’s cozy in here with the Android machine. Select "Permanent Agent" as the mode.

Now, hit "Create". You should now see a gazillion fields to fill in. For the description, I went with something like The smartphone itself because, why not? For the number of executors, I settled on 1, but feel free to tweak it based on your machine’s prowess.
The remote root directory is set to /data/data/com.termux/files/home – that’s our agent’s humble abode, the Termux user’s home turf.

As for labels, I went with aarch64, android – gotta give our Android buddy some identity, right? And for usage, let’s go with "Use this node as much as possible" – it’s eager to help!

Now, for the grand finale, choose "Launch agent via SSH" as the launch method.
Host?
Oh, just good ol' localhost, and for credentials, select our trusty jenkins-agent from earlier.

Oh, but wait! Before we select that final "Save" button, we’re diving into the "Advanced" settings because, well, we’re adventurers! Change the port to 8022 and remember to update the "JavaPath" to /data/data/com.termux/files/usr/bin/java.

Lastly, sprinkle in some digits – 60 for "Connection Timeout in Seconds", 10 for "Maximum Number of Retries", and 10 for "Seconds To Wait Between Retries".

Then, with a dramatic flourish, select "Save" and let the magic unfold!

After a bit of anticipation, select "Nodes" on the left, select "Myself", and give that "Log" button a tap and voilà! You should see something like this:

As you can see, the agent is connected, despite being on the same machine as the controller and running on top of Android.
Now, you can use this agent to run your builds on the Android device itself. But…​ there is still a problem with our configuration and we have some ameliorations to make.
On the top right, you can still see a red warning:

We’ll have to address this issue.

Alright, time to tackle that pesky security issue! Hop on over to "Manage Jenkins" > "Nodes", and give a friendly selection to "Built-in Node".
Once there, mosey on over to the left and hit up "Configure". Now, set the number of executors to a solid 0. Then, seal the deal with a satisfying selection of "Save".
Voilà! Watch that red warning vanish into thin air like it’s pulling a magic act!

We’ve officially squashed that security bug and are all set to strut our stuff with our agent, free from any worries.

Your butler won’t lift a finger until the pantry is stocked. Let’s install the bare essentials:

Let’s convince Jenkins to do our bidding.

From the dashboard:

Now scroll to the Pipeline section and decide your scripting fate: Inline script, or Jenkinsfile from SCM.

Need quick results? Choose Pipeline script from the Definition dropdown and paste something like this:

Hit Save, then Build Now. Jenkins will do its thing — you’ll see a glorious Console Output filled with log lines, warnings, and possibly a tiny existential crisis.

If you’re playing for keeps, store your pipeline code in your Git repo.

Create a Jenkinsfile at the root (or wherever makes sense), then:

Now every time Jenkins builds, it’ll grab the latest code and follow the recipe in your Jenkinsfile like a dutiful butler consulting a particularly grumpy cookbook.

Too abstract? Fear not — we’ll now use a real-world-ish example from the friendly folks at the jenkins-docs organization.

We already have Java and Maven on board (thanks to our earlier setup). Let’s double-check:

If Maven doesn’t respond, it’s either shy or not installed. Assuming it talks back, you’re good to go.

Let’s use this GitHub repo: https://github.com/jenkins-docs/simple-java-maven-app It even includes a Jenkinsfile tucked away in the jenkins/ directory — classy.

Now, let’s hook that into Jenkins:

In the next window:

And finally — drumroll — select Build Now. Double-check you’re not on a metered connection unless you really want to download half the internet via Maven.

And there you have it! A full Jenkins build triggered from your Android phone, which, let’s be honest, used to spend its days just doomscrolling and charging. High five, mate!