Jenkins CI uses wrong svn revision for build

Question

currently I am working with Jenkins CI Server and I want to trigger a job/build via svn post commit hook. So far it works as expected, but the build uses the previous svn revision.

For example: I check in my files and the client shows me revision 90, the build starts, but it uses 89.

The post-commit hook looks like that:

UUID=`svnlook uuid $REPOS`
/usr/bin/wget \
     --header "Content-Type:text/plain;charset=UTF-8" \
     --post-data "`svnlook changed --revision $REV $REPOS`" \
     --output-document "-" \
     --timeout=2 \
     http://ci-jenkins/job/Job1/build?rev=$REV 1>&2

The Check-out Strategy in Jenkins in configured "Always check out a fresh copy". What is wrong? I am still starting with that and have much to learn. So please keep that in mind for answering me. :-)

Answer 1

Ran into the same issue and found this:

Basically you need to append @HEAD at the end of the SVN url, e.g.:

http://svn.yourserver.com/svn/project/trunk@HEAD

Answer 2

Make sure that the date/time on the Jenkins server matches the date/time on the SVN server (or is at least behind it).

Pretty sure Jenkins uses the date/time when doing it's checkouts and updates.

Answer 3

Hi, currently I am working with Jenkins CI Server and I want to trigger a job/build via svn post commit hook.

Okay, I'll bite: Why are you not simply allowing Jenkins to be triggered by a Subversion commit?

I've seen people do this for CVS because Jenkins can take a long time to poll CVS to see if a CVS commit has been made. But, Jenkins takes just a few seconds to determine that a Subversion commit has been done.

If you really insist on triggering a Jenkins build yourself, why not simply configure your projects to allow remote triggering? Under the Build Triggers section for each job, you specify a token and then trigger that with wget:

 wget $JENKINS_URL/job/foo?token=BUILD_NOW

(Assuming the token you've set is BUILD_NOW)

This way, you don't have to worry about the revision and Jenkins will build the last revision that was checked in.

Others feel this is a time synchronization issue, but I'm not so sure. You are passing the build number in your argument. You can try a few things:

• Sleep for 30 or so seconds before triggering the build and see if that helps. I wouldn't keep it in the script because it delays the Subversion commit, but it might help you determine that this isn't a timing issue.
• What if you add one to $REV and then trigger the Jenkin's build? Maybe that'll take care of the problem.

Answer 4

This can happen if the time on Jenkins and Subversion server is out of sync. Ensure that the time stays in bounds of a 2 seconds.

Answer 5

this is due to time synchronization between the SVN server and jenkins's one. In other words, the date/time of the two servers is not the same. I have encountered this and i had three minutes of difference, i resolved this by configuring a delay of 5 minutes before the execution of the jenkins job in the advanced options of the project.