Jenkins behaviour when using post-commit hook

Question

I am using post-commit hook to automatically trigger a build for a job configured in Jenkins when user checks in code to Subversion.

When post-commit hook is used, will Jenkins parse out the svn repo url configured in all active jobs when a notifyCommit request is made?? Or will it parse out the svn repo url for a job only if 'poll scm' feature is turned on?

I need to know this because of late SVN is very slow or goes down after reaching its max clients limit(64). My Maxrequestsperchild is 64000. I have about 200 jobs in Jenkins and about 50 of them have 'poll scm' feature turned on.

Any help is appreciated. Thanks

Answer 1

When you trigger Jenkins via a Subversion post-commit hook, you're just sending a URL to the Jenkins job to start the build.

If you look at the Jenkins job configuration page and go down to the Build Triggers section, you'll see an entry for Trigger builds remotely (e.g., from scripts). You give a name of your build token then, and then you can use that URL via a wget or curl command to trigger the build.

The build token is just a string that you can use to force a build. For example, if your Jenkins URL is http://jenkins.vegicorp.com, and your job name is foo-trunk, and you've set your build token to BUILD_ME_NOW, you could trigger the build with:

 wget http://jenkins.vegicorp.com/job/foo-trunk/build?token=BUILD_ME_NOW

What you can do is use a set way of how you name Jenkins jobs, so you can parse your Subversion URL to figure out the URL for the job.

For example, you setup your Subversion repo with the URL /trunk/project or /branches/branch_name/project, and you setup your Jenkins jobs to be project-trunk or project-branch_name.

You can look at the output of the svnlook changed command in your pre-commit hook. You'd chop off the file and directory names, so you just have the project name, and whether the project is on the trunk or a branch.

Then, you'd use that information to munge a build trigger URL. For example, I find that all of the files are under:

 /trunk/foo

I know this is my foo project under trunk, and the Jenkins job should be called foo-trunk. From there, I can figure out that the URL should be $JENKINS_URL/job/foo-trunk?token=BUILD_ME_NOW

With luck, there is a foo-trunk project (Be prepared to handle errors from wget in your post-commit trigger) and running:

 wget $JENKINS_URL/job/foo-trunk?token-BUILD_ME_NOW

will trigger the build.

People like this because they can trigger the build immediately after a commit instead of waiting for the next minute. With CVS, you cannot use polling because polling CVS builds takes so much time and resources.

However, I don't find this an issue with Subversion. Subversion polling is fast and takes few resources. And, I don't mind the fact that I don't build immediately after a commit and an occasional double commit where two people commit changes within the same build isn't a big issue with me. Plus, if Jenkins happened to be down, the build won't be triggered if I depend upon a post-commit hook. If I use the standard Poll SCM trigger, Jenkins will trigger the build once it does come back up.

One place where triggering via post-commit trigger can be helpful is where you use build parameters. For example, instead of a separate foo build for each branch, I define on foo Jenkins project, and one of my parameters is the branch I want to build (or trunk). Now, my post-commit trigger can trigger the build for the correct branch.

I thought the Jenkins had an example of a post-commit Subversion trigger. There is one for CVS would should give you an idea how it works.

---

Found this post-commit hook on the Subversion plugin page for Jenkins.

Answer 2

I am pretty sure it needs to have SCM polling enabled, but you can set up some rare schedule, like once a year.

Edit:
Here is a text from Subversion Plugin documentation, in regards to using post-commit hooks

Jobs on Jenkins need to be configured with the SCM polling option to benefit from this behavior. This is so that you can have some jobs that are never triggered by the post-commit hook (in the $REPOSITORY/hooks directory), such as release related tasks, by omitting the SCM polling option. The configured polling can have any schedule (probably infrequent like monthly or yearly). The net effect is as if polling happens out of their usual cycles.

What it is saying is that if you want a job to be triggered by post-commmit hook, you have to have that job configured with SCM polling (albeit it can be infrequent polling). The builds will happen as many times as the post-commit hook is called, independent of SCM polling interval.

This is done so that you can have a repository location configured with post-commit hooks, and an automatic build job that acts on the hook, while having another manual job for the same repository location but configured without SCM polling that would ignore the post-commit hook.