Perl script sets up Jenkins jobs to automate builds and tests
Automatic Testing
Instead of configuring the Jenkins continuous integration server in the browser with mouse clicks and text input for builds, programmers can store the necessary data in the source control system and let a Perl script do the work.
Continuous integration (CI) and the associated productivity gains are now firm favorites in the development universe. Input the code into the source control system, issue a pull request, have a co-worker check it – already the cogwheels of the CI pipeline grab the change, run it through the ever-growing test suite, and, presto, everything gets released all at once. CI servers like Jenkins [1] or TeamCity [2], which grab the latest source versions of a project and fire up a build with all tests and possible deployment steps, are enjoying growing popularity.
But spending two minutes creating a new build project in Jenkins' recalcitrant interface can wear down the enthusiasm of even the most motivated developers. As Figure 1 shows, the quest here is to find the required boxes, check them, and fill out some text fields.
If every Perl project requires the same command sequence to start the build process, you don't need to keep typing the same info for each new project. And, the question remains: What happens if a few dozen projects move to a new CI server, does this mean starting the insane task of typing and clicking all over again?
Minimalist Thinking
Your very own Perlmeister's vision is of a more minimalist and conventional approach, such as the one adopted by Travis-CI [3] a long time ago. In this case, a small file in the source code of the project specifies the Git repository from which Jenkins can retrieve the source code and the name under which to run the project on the Jenkins server.
The Perl script presented here then puts together the Jenkins configuration as an XML document and sends it to the server as a POST request via the Jenkins API. The result is that the project is set up without any typing.
No Docs Reading Required
How do you discover the correct format for the XML data without reading the documentation or even the Jenkins source code? Manually entering a test project in the Jenkins interface and then retrieving its XML representation reveals the secret, as shown in Figure 1. The developer here enabled Git as an option for the source code repository and then typed the URL for the GitHub project into the text box that appeared.
The project is called log4perl
on the Jenkins server, and the script in Listing 2 can easily read the associated XML data via the API. The CPAN Jenkins::API module provides the project_config()
method, which contacts the server on port 8080 of the localhost in the script and requests the configuration, supplying the project name.
Listing 2
jenkins-project-xml
First of all, however, a script like the one in Listing 1 [4] should check to see whether the Jenkins server responds to requests on the default port. If this works, Listing 2 can inquire as to what the configuration of a particular project looks like.
Listing 1
jenkins-ok
Configuration Jungle
If successful, the project_config()
method returns a tangled nest of XML, which – among other things – reveals the values for the URL pointing to the project's Git repository, as manually entered in the web UI (Figure 2).
Armed with this example, a script like that shown in Listing 3 can put together a template with an XML structure and use variables (e.g., [% git_url **%]
) interpreted by the CPAN Template Toolkit module to adapt them for existing projects (Figure 3).
Listing 3
jenkins-projects-sync
The script reads the minimum configuration of each project from the YAML data in Listing 4, consisting of the project name (e.g., log4perl
) and the URL for the source code on GitHub.
Listing 4
jenkins-projects.yml
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.