Jenkins - Build loop

Question

Solutions

When configing the branchs to build remove the wildcard *:

*/master to be only master

---

This error only occours when a GIT SCM is related to the JOB.

Ex: I have a daily job to build an Android project. First i thought that it was a cron problem, currently im using 50 10 * * *, but i have tried H 10 * * * without any success. When the time comes, it always build the job (Failure or Success) and it queue another job.. and so on...

Would last have run at Friday, May 22, 2015 10:01:58 AM BRT; would next run at Saturday, May 23, 2015 10:01:58 AM BRT.

Even a build with parameter it queue a another job everytime.

So it stays in a build loop, forever..

---

Config:

• Jenkins ver. 1.614.
• Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-46-generic x86_64)
• GIT client plugin: 1.17.1
• GIT plugin: 2.3.5

---

Console Output:

Started by an SCM change
Building in workspace .../jobs/PROJECT_NAME/workspace
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url ssh://GIT_ADDRESS/ # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from ssh://GIT_ADDRESS/
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress ssh://GIT_ADDRESS/ +refs/heads/master:refs/remotes/origin/master
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Multiple candidate revisions
Scheduling another build to catch up with PROJECT_NAME
Checking out Revision e6d726c2d31cb0d7e6fad4362ee85e6fac1712c6 (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f e6d726c2d31cb0d7e6fad4362ee85e6fac1712c6
 > git rev-list e6d726c2d31cb0d7e6fad4362ee85e6fac1712c6 # timeout=10
[Gradle] - Launching build.
[android] $ gradle clean build assemble
...

Maybe the problem is this?

 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Multiple candidate revisions
Scheduling another build to catch up with PROJECT_NAME

---

The build loop:

---

Job Config:

---

Global Config:

---

Answer 1

Review the beginning of the console logs, for both the job that you manually started, and the job that gets queued next automatically.

In the beginning of the console log, it gives a reason for why the build was triggered, for example 09:46:05 Started by an SCM change or 16:06:58 Started by user Slav. Please add to the question the start of both console logs.

Edit:
Now that we know that Jenkins detects an SCM change trigger we can further speculate that what's causing this behaviour is an SCM post-commit hook of some sort, or another script activation sending a request to Jenkins.

Post-commit hooks should not work if SCM polling is not enabled, but nothing else makes sense, so let's investigate that avenue. Add /pollingLog/ to the build URL of the build number that was triggered "by SCM change". There is a chance that nothing would be found, but if there is, but let's make sure.

Next, if possible, bind Jenkins to a different IP address and/or port. If there are "rogue" scripts that are triggering secondary builds, they won't be able to adapt to changed address.

Edit 2:
Looks like there is a bug in git client plugin itself, it was fixed in version 1.6.2. Please check the version of your git plugins.
Sources: https://issues.jenkins-ci.org/browse/JENKINS-10767 and https://issues.jenkins-ci.org/browse/JENKINS-20286