Jenkins parameterized job that reuses old build with same parameters

Question

Background: We have a number of Jenkins top-level jobs that uses (and shares) other jobs as sort-of subroutines. To control the overall flow we use the Jenkins Parameterized Trigger Plugin.

The top-level jobs then gather test reports, build reports etc. from the sub-builds and conveniently publishes them in one go. It's working really well.

Problem at hand: Each of the top-level jobs are started with a number of parameters, and only a selection of these are passed on to the sub-jobs. For some sub-jobs, the parameters are the same as they were some time ago, when the sub-job was last called from this top-level job, but our top-level script isn't aware of this. In essence, we waste build time, building the sub-job again with the same parameters.

In a perfect world the Parameterized Trigger Plugin would have an option like

• Do not rebuild job if identical parameters (and configuration unchanged).

which would perform the following steps:

1. Compare the build-parameters of all kept builds of the given job, to the current parameters.
2. If the job-configuration is unchanged since the found job was build, setup environmental variable to point to the old job that was found above.
3. If job not found or the job-configuration has been changed since the found job was build, perform the build as usual.

Unfortunately it does not seem to exist, nor can I find an alternative plugin that provides the functionality I seek.

Groovy to the rescue? This is where I guess the Scriptler Plugin and a Groovy Script would come in handy, as it would allow me to perform the check in the sub-job, and then set an environment variable that I can use in the Conditional BuildStep Plugin to either perform the build as usual, or skip the build and setup the build environmental variables using the EnvInject Plugin.

My programming question: I'm new to Groovy, and to JAVA for that matter. I have lots of other (assembly, C and scripts) programming experience, though. I've searched for example scripts all over, but haven't found anything remotely similar to what I want to do here. Any hints on how to perform this, including alternative takes on the functionality, would be highly appreciated!

Answer 1

You're going in the right direction already. As there's no ready-made plugin available, the best way to implement a custom solution is to use Groovy.

Conceptually, it will be better to implement the "build-or-dont-build" decision on the triggering side (i.e., in the top-level job). This is because once a sub-job has been triggered, it will be difficult (and awkward) to prevent its actual execution or to re-use previous results in case of identical parameters. (The latter basically means implementing memoization for your sub-jobs; it's an interesting feature as such -- AFAIK there's no plugin for that, but it could be implemented with some scripting in the sub-jobs).

Regarding your programming question: personally, I also started from a more embedded/C-ish background. From my experience, if you're planning to work closer and longer with Jenkins, then learning Groovy will definitely pay off. I was reluctant initially to learn "just another scripting language", but Groovy has some very interesting concepts, and you will be able to control Jenkins in a much more flexible, powerful and efficient way than by just using plugins or the external REST/CLI APIs. You will also be less dependent on finding and running too many plugins, which is a plus from administration pov.