Triggering Jenkins jobs from the SCM push to avoid the evil polling


If you have a continuous integration infrastructure with Jenkins you might have you jobs configured to make polling over your SCM in order to trigger a job when there are changes. But this has some problems when Jenkins has several nodes and there are a big amount of jobs.

In my case, i configured the Jenkins jobs to poll the SCM repository ( Mercurial ) every 5 minutes. What that means?

  • A very big load in the SCM repository server due to the big amount of pollings from every Jenkins job.
  • Unexpected behaviour of the polling due to Jenkins bugs or SCM plugin bugs ( at least in the Mercurial one )
    • Jobs launched with no changes because the polling couldn’t be done because maybe the workspace of the previous build is not available
    • Jobs not launched although there are changes because of the loss of threads that manage the channel connections between the master and the slaves (Jenkins bug)

Continue reading


Fixing the postbuild order problem of the upstream/downstream solution i wrote

Some days ago i wrote a post about how to get the overall status in the upstream job from the downstream jobs in Hudson or Jenkins (

A user (v22 ) test my code and had some problems, and actually, there is a problem.

As i said in the comment reply, there is a problem in the execution order of the post build actions, this is not deterministic and depends on how the job configuration is stored in a XML file located in the master node.

The relationship between the upstream jobs and the downstream jobs is ready when the fingerprints are recorded. This action is done on a post build action, like the Groovy execution. If the Groovy execution is performed before the fingerprint recording, there is not upstrem job set yet, therefore the Groovy code fails.

I proposed in that reply a workaround to change the order execution of the post build actions, but this is not working as i expected, so there is not a way to force the Groovy execution after the fingerprint recording.

There is an open ticket in the Jenkins and Hudson issue tracker to add a way to specify the post build actions executions:

But everything has a solution, and a solution that always works 😉

Continue reading

Jenkins / Hudson getting the overall status in the upstream job from the downstream jobs

Few days ago i asked in this question:

I wanted to get the result of the upstream job depending on the result of the downstream jobs. I mean:

If in the upstream job i get a “stable” result but if in one of the downstream jobs i get an “unstable” or “failed” result i want to get the worst status in my upstream job.

In my case, i wanted to speed up the test execution paralellizing the build in different downstream jobs, therefore, i wanted to have the overall result of the build in the main job (the upstream) in order to see the result of the complete build in a single point.

I couldn’t find any good solution, only workarounds. So i started to investigate and discovered the best Jenkins / Hudson plugin i have ever seen: the Groovy Postbuild plugin

With this plugin you can do almost whatever you want with Jenkins / Hudson. It allows you to execute a Groovy script in the post build phase and offers you the “build” and “hudson” Java objects.

The solution for my problem was a simple Groovy script added in the downstream jobs. This code gets the upstream job, access to the last build, check the result and if its result is better than the downstream one, it updates it.

This is the piece of code:

Continue reading