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?

Kohlrabi

Having the same problem now. Hudson polls the repository timely, however it builds every time despite no changes. How can this be the default setting? – Edytheee

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.

Kohlrabi

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.

Servia

Yeah, I'd thought of that approach, but I didn't really want to implement it, as I didn't want want to assume that every project in the SVN repo had a corresponding build in Jenkins (Yes, I could modify the post-commit to only work on some projects, but then I'd have to change that again whenever a new project is created in the repo that I wanted Jenkins to manage). But, unless I get the polling working properly, the post-commit is the only other way I can think of going. – Kohlrabi

it turns out that the answer to my problem was to use the http:// protocol in Jenkins in the location of my repo. Apparently it doesn't support the svn:// protocol. Everything works now with that change. – Kohlrabi

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.

Carmichael

The time difference really depends on your hook - we pass the revision number to Jenkins, and it builds that revision. I think this is trickier if you are using Jenkins built in SCM to get the code, but it is possible. – Servia

@David - I've found the solution, apparently the svn:// protocol isn't supported, as after I changed my SVN server and Jenkins to use http:// things worked them selves out. Thanks for the help. – Kohlrabi

Answer 4

It could be an issue with the SVN plugin. See here Issue 10222.

Crinkly