-
Bug
-
Resolution: Fixed
-
Major
-
None
A change introduced since the release of git plugin 2.3.5 has caused the plugin to start a new build each time the git server is polled for changes. It does not do that for every job, and I'm not clear why it does it for this specific job definition, but I've confirmed several times that this configuration has the problem, and that it did not have the problem with 2.3.5 and earlier.
Steps to duplicate the problem:
- Clone a docker repo with the base config on a branch
git clone https://github.com/MarkEWaite/docker.git - checkout the docker branch to show the problem
cd docker git checkout -b master-JENKINS-26179-poll-now-always-starts-a-build -t origin/master-JENKINS-26179-poll-now-always-starts-a-build
- Build the docker image
sudo docker build -t markewaite/JENKINS-26179 .
- Run the docker image
sudo docker run -p 9090:8080 -p 50000:50000 -i -t markewaite/JENKINS-26179
- Create the job
java -jar jenkins-cli-jar -s http://localhost:9090 create-job JENKINS-26179 < JENKINS-26179.xml - Poll for changes so the job will build - Confirm that it builds 5 times (once for each branch)
- Press "Poll Now" - Confirm that (as expected) it does not build again
- Install git plugin pre-release 2.3.6
- Restart Jenkins (to activate the enw git plugin version)
- Press "Poll Now" - Confirm that (unexpected - the bug) it builds each time "Poll Now" is pressed
- relates to
-
-
- Closed
-
- links to
[JENKINS-29066] Git plugin dev version 2.3.6-0c1a59a8 builds on every poll
| Description |
Original:
A change introduced since the release of git plugin 2.3.5 has caused the plugin to start a new build each time the git server is polled for changes. It does not do that for every job, and I'm not clear why it does it for this specific job definition, but I've confirmed several times that this configuration has the problem, and that it did not have the problem with 2.3.5 and earlier. Steps to duplicate the problem: # Clone a docker repo with the base config on a branch {code:bash} git clone https://github.com/MarkEWaite/docker.git {code} # checkout the docker branch to show the problem {code:bash} cd docker git checkout -b master- {code} # Build the docker image {code:bash} sudo docker build -t markewaite/ {code} # Run the docker image {code:bash} sudo docker run -p 9090:8080 -p 50000:50000 -i -t markewaite/ {code} # Create the job {code:bash} java -jar jenkins-cli-jar -s http://localhost:9090 create-job {code} # Poll for changes so the job will build - Confirm that it builds 5 times (once for each branch) # Press "Poll Now" - Confirm that (as expected) it does not build again # Install git plugin pre-release 2.3.6 # Restart Jenkins (to activate the enw git plugin version) # Press "Poll Now" - Confirm that (unexpected - the bug) it builds each time "Poll Now" is pressed |
New:
A change introduced since the release of git plugin 2.3.5 has caused the plugin to start a new build each time the git server is polled for changes. It does not do that for every job, and I'm not clear why it does it for this specific job definition, but I've confirmed several times that this configuration has the problem, and that it did not have the problem with 2.3.5 and earlier. Steps to duplicate the problem: # Clone a docker repo with the base config on a branch {code} git clone https://github.com/MarkEWaite/docker.git {code} # checkout the docker branch to show the problem {code} cd docker git checkout -b master- {code} # Build the docker image {code} sudo docker build -t markewaite/ {code} # Run the docker image {code} sudo docker run -p 9090:8080 -p 50000:50000 -i -t markewaite/ {code} # Create the job {code} java -jar jenkins-cli-jar -s http://localhost:9090 create-job {code} # Poll for changes so the job will build - Confirm that it builds 5 times (once for each branch) # Press "Poll Now" - Confirm that (as expected) it does not build again # Install git plugin pre-release 2.3.6 # Restart Jenkins (to activate the enw git plugin version) # Press "Poll Now" - Confirm that (unexpected - the bug) it builds each time "Poll Now" is pressed |
| Assignee | Original: Nicolas De Loof [ ndeloof ] | New: Mark Waite [ markewaite ] |
| Remote Link | New: This issue links to "potential fix (Web Link)" [ 12958 ] |
I was able to reproduce and diagnose this issue.
This issue occurs as the remote repo as some branch which is ancestor for another one. On https://github.com/MarkEWaite/JENKINS-26197 you're using to reproduce this issue : master is ancestor for branch-2015-06-10-21-21-21-pe
As the job is built first, all `branch-*` branches get built as expected and master is excluded as hudson.plugins.git.util.GitUtils#filterTipBranches is excluding such non-tip branches. Then during polling (without workspace) master branch is detected as a non-built head, a build is triggered for it, and checkout do exclude it again and do re-build previous commit, resulting in infinite build loop.
I can't find a reasonable workaround for this issue. I propose to introduce a new "FilterTipBranches" advanced behavior to enable hudson.plugins.git.util.GitUtils#filterTipBranches, This one would force use of a workspace for polling, and would be automatically added to any pre-2.3.6 job.
wdyt ?
maybe safer to revert this remote-polling stuff and get 2.3.6 released
proposed to revert on https://github.com/jenkinsci/git-plugin/pull/331
introduce a test to prevent such a regression in future
will investigate further use of ls-remote in a separate branch
I just checked that proposed pull request and confirmed that it resolves the problem.
Code changed in jenkins
User: Nicolas De Loof
Path:
src/test/java/hudson/plugins/git/GitSCMTest.java
http://jenkins-ci.org/commit/git-plugin/199f5e8b175d134942b2b8415f299d52ed92e756
Log:
JENKINS-29066 reproduction testcate
Refer to the updated docker repo for more details on how to duplicate the problem for both JGit and command line git.