Postcommit hook in Jenkins tries to update -all- SVN checkouts with the same revision number

Question

I'm using Jenkins 1.532.1, and I have a Subversion postcommit hook that includes the URL in the Jenkins Subversion module to kick-off a build.

In order for Jenkins to care about the repository that had the commit, it needs to be aware of that repository's UUID. This is secretly done by making sure your repository is among those under "Source Code Management". In my case, I have a battery of other scripts that know how to go, get, and assemble the project, but I also need to explicitly tell Jenkins about it, or its Subversion module will ignore the build request. That's fine... I tell that module to make it an "empty" checkout. No substantial amount of time is lost.

I have two other checkouts defined for that Jenkins job (again, under the "Source Code Management" section). The builds work fine when started by hand, but whenever a build is started as a response to the post-commit hook, it tries to get all three checkouts with the same version number, and naturally fails on the second checkout (the first checkout was the repository that had the postcommit hook).

This is the top of the [sanitized] output:

Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on JenkinsWorker in workspace /home/builder/jenkins/workspace/project1
Updating https://buildhost/svn/project1/trunk at revision 3095
At revision 3095
Updating https://buildhost/svn/project1/trunk/build_me at revision 3095
ERROR: Failed to update https://buildhost/svn/project1/trunk/build_me
org.tmatesoft.svn.core.SVNException: svn: E160006: No such target revision '3095' found in the repository.
svn: E175002: REPORT of '/svn/project1/!svn/vcc/default': 500 Internal Server Error (https://buildhost)
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
    at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1293)
    at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:839)
    at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:507)
    at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
    at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
    at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
    at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
    at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
    ...

It's ridiculous. Is there any advice other than "upgrade your Subversion plugin"?

try upgrading first? and see if issue still exists jenkins-ci.org/changelog — Kalpesh Soni
There are over 300 jobs being driven by that system, and only one uses a post-commit hook. It's not worth potentially destabilizing the system, man. — Dustin Oprea
you should have one test jenkins with a few jobs running for testing new plugins/jenkins upgrades - that way you would know that your most important jobs are not broken, but in general i have seen that jenkins upgrades are pretty much painless — Kalpesh Soni

Kalpesh Soni Kalpesh Soni · Accepted Answer · 2014-06-30T21:19:50

https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

This plugin is bundled inside jenkins.war

If your job has multiple Subversion module locations defined, this may lead to inconsistent checkouts - so it's recommended to leave out '?rev=$REV' in that case.

https://wiki.jenkins-ci.org/display/JENKINS/Pinned+Plugins

if you put jpi file for subversion and pin it, it should stick

Postcommit hook in Jenkins tries to update -all- SVN checkouts with the same revision number

1 Answers