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 (ie, 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.