A tool to trigger all Jenkins jobs in a Jenkins folder

Let us assume that you have a Jenkins server, which has a folder containing several Jenkins jobs. We require a method to start all these jobs sequentially and automatically. One can find many solutions to this problem, including a Jenkins pipeline job that executes directly on the Jenkins server, triggering the builds. However, pipeline jobs—which we write in Apache Groovy—are frequently challenging to debug and get working correctly. Let us discuss Jenkins briefly before we continue.

The top-level folder has a project folder called Veracode

Above, you can see that, there is a Veracode top-level folder that contains our Jenkins jobs.  Each job is a separate compilation unit, in our case, each project is a microservice.

Detailed projects for static code analysis Jenkins job/project view showing dummy pipeline run

The above screenshot shows one project. We need to do the equivalent of hitting the Build Now button but do so automatically. We will write a program that triggers builds using the Jenkins REST API.

But let’s worry about the authentication first. It would be nice to secure the Jenkins jobs so that they can only be remotely triggered with a provided secret token.

Project config allowing the remote trigger

I usually generate a guid for the auth-token and use the same for all the projects. If your Jenkins server is public, it is important to provide an auth token for build triggers. Our Jenkins server sits behind a firewall, nevertheless having an authentication token to trigger builds is a good thing.

The build properties also contain a reference to the build pipeline that will be used. Given how Jenkins works, this may need some further explanation. A git repository, branch, login information, and a path to a Jenkinsfile—the file containing the Groovy code to run your pipeline—are all specified in the project’s pipeline configuration.

Let us briefly look at the veracodePipeline file, which is listed below.

Disappointing and confusing, right? The @Library means that the real pipeline is not in this file, but rather in a library. In what library? Well in one that is called ‘Jenkins-shared-library’. And what does the @veracode do? Turns out that is a git branch name of the shared library. And what of line 2? It is the groovy method to invoke in the shared library to execute the pipeline.

You may ask what git repository the jenkins-shared-library is referring to, and where credentials for this git repository are specified. The answer is that you can find this if you go to your Jenkins instance and then to the /manage/configure URL. So https://yourinstance.com/manage/configure will get you there.

You do need the pipeline plugin to be active to see the option above. Let us further examine the actual pipeline code.

‘Jenkinsfile’ pipeline code

The script on lines 147-149 does nothing yet, but it’s a start. Whenever we trigger a build, it waits 5 sec and then outputs a message. Perfect for testing the trigger-build (tb) utility. This completes the Jenkins portion of the setup. I will describe the ‘tb’ (Trigger Build) tool in the next post.

Part 4 – The trigger build program


Leave a Reply