Under certain conditions, the Git SCM polling will return false positives. It gets into a state where it is consistently comparing hashes from two different branches, which will always trigger a build. Under some conditions, this can cause a build queue to back up.
Steps to reproduce:
- Jenkins pipeline job, using Jenkinsfile, with branch spec ("Branches to build") set to "*/master"; SCM polling set to some short interval (e.g. 5 minutes)
Note: This behavior was also observed with the branch spec when using "refs/heads/<branchname>" instead of "*/<branchname>"
- Create a new branch
- Commit to that branch and push to the server (to establish the branch on the server)
- Update the Jenkins job config to point to the new branch
- Commit to master and push to the server
- Commit to the new branch and push to the server
The console log of the next build shows that the build itself is pulling from the correct branch (the new branch), but the Git Polling Log shows that the SCM polling is still looking at master.
On the next poll after that, Jenkins queues another build, even if no changes are pushed to the server. The Git Polling Log shows that it is comparing the hash of a commit on master to the hash of a commit on the test branch. This compare will always result in a build being queued. A sample polling log is shown below:
The job will continue queueing builds indefinitely at every SCM polling interval.
Remediating the issue requires disabling the build, cleaning out any unneeded jobs from the queue, and setting the branch spec back to master in the job configuration.