Jenkins Poll SVN builds constantly even with no new commits

Question

I'm trying to setup Jenkins to poll from my SVN repo, and start a new build whenever it detects a commit has gone in. I've gotten the polling part working, but the building is rather overzealous, and right now it is rebuilding every time it polls - whether or not there have been any changes. The SCM-polling.log file reads:

Started on Aug 31, 2011 9:49:51 AM
Workspace doesn't contain svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk. Need a new build.
Done. Took 10 ms
Changes found

The Console Output from Jenkins looks like this:

Started by an SCM change
Checking out a fresh workspace because the workspace is not svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk
Cleaning workspace /var/lib/jenkins/jobs/CSATester/workspace
Checking out svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk
....
no revision recorded for svn://10.64.147.118:/svn/repos/conttest/csa_test/trunk in the previous build
No changesets found for this build

The repo url is set to svn://10.64.147.118:/svn/repos/conttest/trunk and I've told Jenkins to delete unversioned files and then update prior to build. The work space definitely contains the files in the repo, and the build succeeds every time.

Any ideas on what may be causing this?

Answer 1

So, I've found out that it seems the svn:// protocol isn't supported in either Jenkins or the SVN plugin. After changing my SVN server to use http:// and setting that new path in Jenkins, builds are no longer happening unless there is actually a new commit.

TL,DR: Don't use svn://, use http:// instead.

Answer 2

I'm not sure what is causing this, but I've had a lot of issues with SCM polling in the past. I've found that it works better to write an SVN post-commit trigger that hits the url of the build to trigger it. This eliminates the overhead of polling and will never trigger a build if there are no changes. If you wanted to get fancy, you could even make the trigger 'smarter' and avoid compilation on changes of files like readme.txt and the like.

Answer 3

We had a similar issue with CVS where the CVS polling took longer than the time I told it to poll for changes. That is, it would take CVS three minutes to poll for changes, but I was telling it to poll every minute. This shouldn't be an issue with Subversion though.

You can use a post commit hook as Feasoron said, but there are two issues with that approach:

• If Jenkins/Hudson is down when the trigger is hit, Jenkins/Hudson won't do a build.
• If there is any time difference between the Jenkins/Hudson server (even just a few seconds), you could end up with Jenkins/Hudson building the older version of the repository.

Most people have Subversion polling in Jenkins/Hudson and don't have these issues, so it's probably related to something in your setup.

Take a look at the polling logs for each build and see why Jenkins/Hudson believes it sees an update (available in each build as a link on the left hand side of the webpage). Also look at the first few lines of your build console and see if that's offering any clues.

If you are still can't figure it out, update your question with a few of the polling logs and that might help us understand why you're having these issues.