As I keep saying, polling a repository from Jenkins is inefficient; it adds delay on the order of minutes before a build starts after a commit is pushed, and it adds additional loads. It is much better instead to do push-notification from the repository. In this post, I’m going to explain how to do this for Git, which brings this on par with Subversion.
The previous best practice of doing this is best summarized in this blog post. While it works, it is less than ideal. A part of the problem is that this requires hard coding of job names inside the repository hooks, making it hard to keep them up-to-date. Another problem is that if your job only cares about one branch in a busy repository, you don’t want a new build to be triggered. Finally, the last problem is that you need some extra work for secured Jenkins.
With the latest Git plugin 1.1.14 (that I just released now), you can do this more easily by simply executing the following command:
curl http://yourserver/jenkins/git/notifyCommit?url=
This will scan all the jobs that’s configured to check out the specified URL, and if they are also configured with polling, it’ll immediately trigger the polling (and if that finds a change worth a build, a build will be triggered, in turn). This allows a script to remain the same when jobs come and go in Jenkins. Or if you have multiple repositories under a single repository host application (such as Gitosis), you can share a single post-receive hook script with all the repositories. Finally, this URL doesn’t require authentication even for secured Jenkins, because the server doesn’t directly use anything that the client is sending. It runs polling to verify that there is a change before it actually starts a build.
One more final note — in Git, unlike Subversion, a repository does not have its own identity, and a single repository sometimes has multiple URLs to access it. In such a case, simply execute the curl commands multiple times with all the different URLs.
That’s it. I hope this will help reduce the use of polling and have more people switch to push notifications. It really is addictive to see the build start in a split second after you push a change.
— Kohsuke
Comments
I forgot to put the credit where it is due. Much o...
Any chance of this making its way to the Mercurial...
Kamil, It's actually not that hard to do this...
Thanks Kohsuke, I'll give it a try. I haven...
Cool! Let us know if you need any help. See https:...
“a repository does not have its own identity”—you ...