In Jenkins, SCM polling is easy to configure, and uses the same cron syntax we discussed previously.
The natural temptation for SCM polling is to poll as often as possible (for example, using “
*”, or once every minute). Since Jenkins simply queries the version control system, and only kicks off
a build if the source code has been modified, this approach is often reasonable for small projects. It
shows its limits if there are a very large number of build jobs, as this may saturate the SCM server and
the network with queries, many of them unnecessary. In this case, a more precise approach is better,
where the Jenkins build job is triggered by the SCM when it receives a change. We discuss this option
in Section 5.5.4, “Triggering Builds Remotely”.
If updates are frequently committed to the version control system, across many projects, this may cause
many build jobs to be queued, which can in turn slow down feedback times further. You can reduce the
build queue to some extent by polling less frequently, but at the cost of less precise feedback.
If you are using CVS, polling may not be a good option. When CVS checks for changes in a project, it
checks each file one by one, which is a slow and tedious process. The best solution here is to migrate to
a modern version control system such as Git or Subversion. The second-best solution is to use polling
at very sparse intervals (for example, every 30 minutes).
5.5.4. Triggering Builds Remotely
Polling can be an effective strategy for smaller projects, but it does not scale particularly well—with
large numbers of build jobs, it is wasteful of network resources, and there is always a small delay between
the code change being committed and the build job starting. A more precise strategy is to get the SCM
system to trigger the Jenkins build whenever a change is committed.
It is easy to start a Jenkins build job remotely. You simply invoke a URL of the following form:
http://SERVER/jenkins/job/PROJECTNAME/build
For example, if my Jenkins server was running on http://myserver:8080/jenkins, I could start the
gameoflife build job by invoking the following URL using a tool like wget or curl:
$ wget http://myserver:8080/jenkins/job/gameoflife/buildThe trick, then, is to get your version control server to do this whenever a change is committed. The
details of how to do this are different for each version control system. In Subversion, for example, you
would need to write a post-commit hook script, which would trigger a build. You could, for example,
write a Subversion hook script that parses the repository URL to extract the project name, and performs
a wget operation on the URL of the corresponding build job:
JENKINS_SERVER=http://myserver:8080/jenkins
REPOS="$1"
PROJECT=<Regular Expression Processing Goes Here>¶
/usr/bin/wget $JENKINS_SERVER/job/${PROJECT}/build