Jenkins: SCM triggers constant builds despite a change

advertisements

We have a problem where despite no code changes SCM is triggering a build. SCM polls for changes every 15 minutes and should only trigger a build if changes are found.

Here are a few examples of consecutive SCM polling log.

Started on Nov 15, 2013 11:47:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.23 sec
Changes found

Started on Nov 15, 2013 11:17:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.22 sec
Changes found

Started on Nov 15, 2013 11:02:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.2 sec
Changes found

As you can see the revision is the same and matches that of

Git Build Data

Revision: 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 origin/develop

These jobs behaved as expected until a few days ago. There is nothing that we're aware that has changed about our environment to cause this.

I upgraded to the latest version of Jenkins (1.539) and installed plug-ins last night in a effort to resolve this but the behavior continues.


I just ran into Jenkins continuously building due to an SCM change, even when there was no change, and polling was not even turned on. This may be different from your scenario but I figured it may still help to share my solution.

Out project is configured to build using the branch specifier */integration just like all of our other integration builds. However, after looking at all of the branches on our origin git repo, I saw that there are two branches that matched the */integration specifier. It looks like a developer must have erroneously pushed to a new branch with a very similar name:

$git branch --remote | grep integration
  origin/integration
  origin/origin/integration

The solution that fixed this issue for me was to specify the branch fully, using refs/heads/integration. I assume it would also work to simply delete the duplicate offending branch, but by specifying the branch exactly I can avoid running into the same problem in the future.

I'm not sure this is the same cause for your problem but this is what worked for me, and hopefully will work for someone else in this situation.