Jenkins is open-source automation software that tries to automate parts of the software development process. When you submit code, for example, Jenkins will grab it, build the project with it and run any tests on it. If you have a large number of people submitting new code or data, Jenkins will wait and grab a bunch of the submissions to build. Depending on the size of the project, this can take a while, and if there’s a problem, you need to know quickly so that people aren’t waiting on a broken build. Email’s fine for this, but [dkt01] saw one of the desktop LED Christmas tree projects on Hackaday, and integrated it into his Jenkins system.
Like the other projects, WS2812b LED rings are used as the tree, and an Arduino Pro Mini runs the show, with an Ethernet LAN Module to communicate with the Python script that monitors the Jenkins build job. The Python script sends commands to the Arduino, which in turn lights up the LEDs. They light up green on a successful build and red if something fails, but during the build process, the LEDs show the current state of the build, tracking Jenkins’ progress as it builds.
Our previous Jenkins post used a big, red LED light that would light up if the build failed. [dkt01]’s build lets you know if the build is successful or has failed, but the build progress is a great addition.
Continue reading “Jenkins Lights the Christmas Tree”
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!