-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Git Plugin 3.3.2
Jenkins 2.60.1
I have a repository which is setup to perform git polling, and it always triggers, suggesting there are changes, even though there are not.
In this case, the job has multiple checkouts using a pipeline, but I think it would only happen in the case of a single checkout as well.
Specifically, the branch name is master, and it checks first all the "remote/branch" combinations, (in this case, "origin/master") and then fails to find anything new (as origin/master was already built). Then, it checks the branch name on its own, thinking that maybe it's a tag or some other ref.
This results in reporting a separate commit (likely whatever master happens to be at when the polling was created), and thus reports a new commit to build. This causes the build to trigger every polling timeout, even though there aren't any real new changes.
Here's a subset of the actual output with repository names and paths redacted. I have the VERBOSE logging enabled for more information.
Started on Apr 3, 2018 4:01:00 PM Using strategy: Default [poll] Last Built Revision: Revision 72c4cea985bb5ff14813d27dac94f34887cbd841 (refs/remotes/origin/master) using GIT_SSH to set credentials > git ls-remote -h <groovyLibURL> # timeout=10 Found 1 remote heads on <groovyLibURL> [poll] Latest remote head revision on refs/heads/master is: 72c4cea985bb5ff14813d27dac94f34887cbd841 - already built by 1738 Using strategy: Default [poll] Last Built Revision: Revision cc24044526e9d460c74a59fcdeb12e43a446cb7d (origin/master) > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url <mainRepositoryURL> # timeout=10 Fetching upstream changes from <mainRepositoryURL> > git --version # timeout=10 using GIT_SSH to set credentials > git fetch --no-tags --progress <mainRepositoryURL> +refs/heads/*:refs/remotes/origin/* Polling for changes in getCandidateRevisions(true,master,,,hudson.plugins.git.util.BuildData@3fcd3164[scmName=<mainRepositoryName>,remoteUrls=[<mainRepositoryURL>],buildsByBranchName={origin/master=Build #1738 of Revision cc24044526e9d460c74a59fcdeb12e43a446cb7d (origin/master)},lastBuild=Build #1738 of Revision cc24044526e9d460c74a59fcdeb12e43a446cb7d (origin/master)]) considering branches to build Qualifying master as a branch in repository origin -> origin/master > git rev-parse origin/master^{commit} # timeout=10 rev-parse origin/master -> AnyObjectId[cc24044526e9d460c74a59fcdeb12e43a446cb7d] AnyObjectId[cc24044526e9d460c74a59fcdeb12e43a446cb7d] has already been built > git rev-parse master^{commit} # timeout=10 Failed to rev-parse: master Using strategy: Default [poll] Last Built Revision: Revision d24e49e865522042434be7b1a46f592aae2608dc (origin/master) > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url <firstRepositoryURL> # timeout=10 Fetching upstream changes from <firstRepositoryURL> > git --version # timeout=10 using GIT_SSH to set credentials > git fetch --no-tags --progress <firstRepositoryURL> +refs/heads/*:refs/remotes/origin/* Polling for changes in getCandidateRevisions(true,master,,,hudson.plugins.git.util.BuildData@857d3e89[scmName=<firstRepositoryName>,remoteUrls=[<firstRepositoryURL>],buildsByBranchName={origin/master=Build #1738 of Revision d24e49e865522042434be7b1a46f592aae2608dc (origin/master)},lastBuild=Build #1738 of Revision d24e49e865522042434be7b1a46f592aae2608dc (origin/master)]) considering branches to build Qualifying master as a branch in repository origin -> origin/master > git rev-parse origin/master^{commit} # timeout=10 rev-parse origin/master -> AnyObjectId[d24e49e865522042434be7b1a46f592aae2608dc] AnyObjectId[d24e49e865522042434be7b1a46f592aae2608dc] has already been built > git rev-parse master^{commit} # timeout=10 rev-parse master -> AnyObjectId[d24e49e865522042434be7b1a46f592aae2608dc] AnyObjectId[d24e49e865522042434be7b1a46f592aae2608dc] has already been built Using strategy: Default [poll] Last Built Revision: Revision 93a6d3510777096a6fbd7f16ac22c28ef4bd872e (origin/master) > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url <secondRepositoryURL> # timeout=10 Fetching upstream changes from <secondRepositoryURL> > git --version # timeout=10 using GIT_SSH to set credentials > git fetch --no-tags --progress <secondRepositoryURL> +refs/heads/*:refs/remotes/origin/* Polling for changes in getCandidateRevisions(true,master,,,hudson.plugins.git.util.BuildData@2e191547[scmName=<secondRepositoryName>,remoteUrls=[<secondRepositoryURL>],buildsByBranchName={origin/master=Build #1738 of Revision 93a6d3510777096a6fbd7f16ac22c28ef4bd872e (origin/master)},lastBuild=Build #1738 of Revision 93a6d3510777096a6fbd7f16ac22c28ef4bd872e (origin/master)]) considering branches to build Qualifying master as a branch in repository origin -> origin/master > git rev-parse origin/master^{commit} # timeout=10 rev-parse origin/master -> AnyObjectId[93a6d3510777096a6fbd7f16ac22c28ef4bd872e] AnyObjectId[93a6d3510777096a6fbd7f16ac22c28ef4bd872e] has already been built > git rev-parse master^{commit} # timeout=10 rev-parse master -> AnyObjectId[4bf94e5146026ba4e3bebef3b2ebf8a795d0d0f8] Found a new commit AnyObjectId[4bf94e5146026ba4e3bebef3b2ebf8a795d0d0f8] to be built on master {0} seems to be a non-branch reference (tag?) > git log --full-history --no-abbrev --format=raw -M -m 93a6d3510777096a6fbd7f16ac22c28ef4bd872e..4bf94e5146026ba4e3bebef3b2ebf8a795d0d0f8 # timeout=10 Using strategy: Default [poll] Last Built Revision: Revision a4db49e3433ef3304c7956e81369c2ed5fa69b5d (origin/master) > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url <thirdRepositoryURL> # timeout=10 Fetching upstream changes from <thirdRepositoryURL> > git --version # timeout=10 using GIT_SSH to set credentials > git fetch --no-tags --progress <thirdRepositoryURL> +refs/heads/*:refs/remotes/origin/* Polling for changes in getCandidateRevisions(true,master,,,hudson.plugins.git.util.BuildData@49f3b5e7[scmName=<thirdRepositoryName>,remoteUrls=[<thirdRepositoryURL>],buildsByBranchName={origin/master=Build #1738 of Revision a4db49e3433ef3304c7956e81369c2ed5fa69b5d (origin/master)},lastBuild=Build #1738 of Revision a4db49e3433ef3304c7956e81369c2ed5fa69b5d (origin/master)]) considering branches to build Qualifying master as a branch in repository origin -> origin/master > git rev-parse origin/master^{commit} # timeout=10 rev-parse origin/master -> AnyObjectId[a4db49e3433ef3304c7956e81369c2ed5fa69b5d] AnyObjectId[a4db49e3433ef3304c7956e81369c2ed5fa69b5d] has already been built > git rev-parse master^{commit} # timeout=10 rev-parse master -> AnyObjectId[00f059f63e272c44fb3f754be4e2f4a1b474c416] Found a new commit AnyObjectId[00f059f63e272c44fb3f754be4e2f4a1b474c416] to be built on master {0} seems to be a non-branch reference (tag?) > git log --full-history --no-abbrev --format=raw -M -m a4db49e3433ef3304c7956e81369c2ed5fa69b5d..00f059f63e272c44fb3f754be4e2f4a1b474c416 # timeout=10 Using strategy: Default [poll] Last Built Revision: Revision 06188df26697ef38293a8533ce601934762c7d6c (origin/master) > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url <fourthRepositoryURL> # timeout=10 Fetching upstream changes from <fourthRepositoryURL> > git --version # timeout=10 using GIT_SSH to set credentials > git fetch --no-tags --progress <fourthRepositoryURL> +refs/heads/*:refs/remotes/origin/* Polling for changes in getCandidateRevisions(true,master,,,hudson.plugins.git.util.BuildData@dff532d1[scmName=<fourthRepositoryName>,remoteUrls=[<fourthRepositoryURL>],buildsByBranchName={origin/master=Build #1738 of Revision 06188df26697ef38293a8533ce601934762c7d6c (origin/master)},lastBuild=Build #1738 of Revision 06188df26697ef38293a8533ce601934762c7d6c (origin/master)]) considering branches to build Qualifying master as a branch in repository origin -> origin/master > git rev-parse origin/master^{commit} # timeout=10 rev-parse origin/master -> AnyObjectId[06188df26697ef38293a8533ce601934762c7d6c] AnyObjectId[06188df26697ef38293a8533ce601934762c7d6c] has already been built > git rev-parse master^{commit} # timeout=10 Failed to rev-parse: master Done. Took 6.5 sec Changes found
I am highly suspect that the relevant commit related to why this breaks is:
c7dae80b85c1 ("JENKINS-21952 Resolve tags with slashes", 2014-02-27)
I believe what is happening is that the "remote/branch" output is failing to find any new changes, so we fall back to attempting to resolve the name like a tag, but it so happens that the polling setup actually does end up with the branch checked out, and it results in us finding the local master name and reporting it.
I don't really know how to resolve this yet.
- relates to
-
JENKINS-50401 Checkout resolution misbehaves with local branch and forward slashes
-
- Open
-
I'm having the same issue. My github enterprise repo has two branches - "master" and "0.0.1" - and I have two jenkins jobs defined (one for each branch... i.e. the branch specifier in each job definition is set to "*/<branchname>"). In my github repository, I've configured the webhook url (https://<jenkins-host>/git/notifyCommit?url=<github-repo-url>&branches=master,0.0.1). When I hit the webhook URL (testing from github), jenkins receives the POST and pokes the correct jobs, but it incorrectly things there are changes on each of the branches, so it triggers a build for each one.
While trying to get the git push triggering to work with the GitHub plugin, I see the same exact behavior. A push to one branch triggers both builds to start, even though the push was to only one of the branches. So it seems like the basic issue here is when the git plugin looks to see if there are changes on a branch, it always thinks there are changes even when no commits have been pushed since the last build.
Edit: In case it matters, I'm using Jenkins v2.89.2 with the Git Plugin v3.8.0
Edit: Just wanted clarify a couple things... I think my scenario is simpler than the one described by the issue originator. I temporarily changed one of my jobs (for the 0.0.1 branch) to use polling (every 2 minutes for testing purposes) rather than the webhook. Without any changes being pushed to my 0.0.1 branch, the first time the polling ran it thought there were changes present so it triggered a build. And subsequent to that, each time the polling is initiated (every 2 minutes), it thinks there is a change and triggers a build. Is there anything I can do via configuration to fix this? Also, if there is some additional server logging that I can enable to try to determine why this is broken, I'm happy to do that as well.
Thanks!