Picture of the miniJen structure on a presentation desk

A Jenkins Demo Stand For Modern Times

Once you’re working on large-scale software projects, automation is a lifesaver, and Jenkins is a strong player in open-source automation – be it software builds, automated testing or deploying onto your servers. Naturally, it’s historically been developed with x86 infrastructure in mind, and let’s be fair, x86 is getting old. [poddingue], a hacker and a Jenkins contributor, demonstrates that Jenkins keeps up with the times, with a hardware demo stand called miniJen, that has Jenkins run on three non-x86 architectures – arm8v (aarch64), armv7l and RISC-V.

There’s four SBCs of different architectures involved in this, three acting as Jenkins agents executing tasks, and one acting as a controller, all powered with a big desktop PSU from Pine64. The controller’s got a bit beefier CPU for a reason – at FOSDEM, we’ve seen it drive a separate display with a Jenkins dashboard. It’s very much a complete demo for its purpose, and definitely an eyecatcher for FOSDEM attendees passing by the desk! As a bonus, there’s also a fascinating blog post about how [poddingue] got to running Jenkins on RISC-V in particular.

Even software demonstrations get better with hardware, and this stood out no doubt! Looking to build a similar demo, or wondering how it came together? [poddingue] has blog posts on the demo’s structure, a repo with OpenSCAD files, and a trove of videos demonstrating the planning, design and setup process. As it goes with continuous integrations, we’ve generally seen hackers and Jenkins collide when it comes to build failure alerts, from rotating warning lights to stack lights to a Christmas tree; however, we’ve also seen a hacker use it to keep their firmware size under control between code changes. And, if you’re wondering what continuous integration holds for you, here’s our hacker-oriented deep dive.

Jenkins And Slack Report Build Failure! Light The Beacons!

When you have a large software development team working on a project, monitoring the build server is an important part of the process. When a message comes in from your build servers, you need to take time away from what you’re doing to make sure the build’s not broken and, if it’s broken because of something you did, you have to stop what you’re doing, start fixing it and let people know that you’re on it.

[ridingintraffic]’s team uses Jenkins to automatically build their project and if there’s a problem, it sends a message to a Slack channel. This means the team needs to be monitoring the Slack channel, which can lead to some delays. [ridingintraffic] wanted immediate knowledge of a build problem, so with some software, IoT hardware, and a rotating hazard warning light, the team now gets a visible message that there’s a build problem.

An Adafruit Huzzah ESP8266 board is used as the controller, connected to some RF controlled power outlets via a 434MHz radio module. To prototype the system, [ridingintraffic] used an Arduino hooked up to one of the RF modules to sniff out the codes for turning the power outlets on and off from their remotes. With the codes in hand, work on the Huzzah board began.

An MQTT broker is used to let the Huzzah know when there’s been a build failure. If there is, the Huzzah turns the light beacon on via the power outlets. A bot running on the Slack channel listens for a message from one of the developers saying that problem is being worked on, and when it gets it, it sends the MQTT broker a message to turn the beacon off.

There’s also some separation between the internal network, the Huzzahs, and the Slack server on the internet, and [ridingintraffic] goes over the methods used to communicate between the layers in a more detailed blog post. Now, the developers in [ridingintraffic]’s office don’t need to be glued to the Slack channel, they will not miss the beacon when it signals to start panicking!