Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-21464

Unwanted repetitive builds of the same git commit hash

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: git-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      In our team we are facing the problem of unwanted repetitive builds of the same commit hash.

      I looked into the sources of git-plugin, switched on verbose logging with "-Dhudson.plugins.git.GitSCM.verbose=true" and found that storing BuildData map of already built branches in build.xml does not work well if the job is configured to run concurrently ("Execute concurrent builds if necessary"). As discussed in https://github.com/jenkinsci/git-plugin/pull/163, saving the map in the job root could solve the problem. However, currently running builds (one or even more) of the job must also be taken into account to prevent single commit to be built several times in a chain.

      Jenkins and plugins versions: 1.532.1, git-plugin 2.0.1, git-client-plugin 1.6.1

      Detailed job setup:

      • maven project - full compilation with all tests
      • job is started via push hook from git (notifyCommit?...&branch=...)
      • Branch specifier matches only master, feature and bugfix branches, but ignores personal and other branches.
        Branch specifier=":origin/(master|bugfix/S14|feature/S14).*"
        It is in regex format because we use name convention for feature/bugfix branches in the form feature/sprint/jiraIssueAndOptionalText, e.g. feature/S14.02/JIRA-123
      • as there are more developers working independently of each other, the job should allow to start concurrent builds as soon as possible after the developer pushes a new branch/commit
      • configured Post-build action "Set build description" to set "${GIT_BRANCH}, ${GIT_COMMIT}" for both success and failed builds

      I tried to prepare a small repository to demonstrate the problem - without success. It seems the problem is related to the size of the repository - when cloning takes longer time.

      We suggest that calls of determineRevisionToBuild and buildData.saveBuild (at least the scheduled commit to build) in hudson.plugins.git.GitSCM#checkout should be as close as possible, before the branch checkout starts (git.checkoutBranch).

      Here it is what happens for a copy of real-size repository (workspace about 1.5GB) with just 4 branches, in a clean new Jenkins job (NotifyCommitTest3), just single push "git/notifyCommit?url=...&branch=master":

      Build History:

      Success > Console Output  #6 	Jan 21, 2014 11:31:17 PM	 13 KB
      	origin/feature/S14.02/stash-jenkins-test, 549bbb10e97a90b1f26db59529ba861797771ccc
      Success > Console Output  #5 	Jan 21, 2014 11:31:12 PM	 12 KB
      	origin/master, 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c
      Success > Console Output  #4 	Jan 21, 2014 11:31:07 PM	 12 KB
      	origin/master, 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c
      Success > Console Output  #3 	Jan 21, 2014 11:31:03 PM	 11 KB
      	origin/bugfix/S14.02/stash-jenkins-test, 6fa2f3f32e94997c84c9a49b36c6346565ce8851
      Success > Console Output  #2 	Jan 21, 2014 11:30:09 PM	 11 KB
      	origin/bugfix/S14.02/stash-jenkins-test, 6fa2f3f32e94997c84c9a49b36c6346565ce8851
      Success > Console Output  #1 	Jan 21, 2014 11:28:49 PM	 11 KB
      	origin/bugfix/S14.02/stash-jenkins-test, 6fa2f3f32e94997c84c9a49b36c6346565ce8851
      

      Build #1:

      Started by an SCM change
      [EnvInject] - Loading node environment variables.
      Building remotely on ch06bl09.mgmt.lmc.cz in workspace /srv/jenkins/workspace/NotifyCommitTest3
      Using strategy: Default
      Cloning the remote Git repository
      Cloning repository ssh://git@stash.int.lmc.cz:7999/rec/g2.git
      Fetching upstream changes from ssh://git@stash.int.lmc.cz:7999/rec/g2.git
      Fetching upstream changes from ssh://git@stash.int.lmc.cz:7999/rec/g2.git
      getCandidateRevisions(false,null,,,null,remoteUrls=[ssh://git@stash.int.lmc.cz:7999/rec/g2.git],buildsByBranchName={},lastBuild=null]) considering branches to build
      Seen branch in repository origin/bugfix/S14.02/stash-jenkins-test
      Seen branch in repository origin/feature/S14.02/stash-jenkins-test
      Seen branch in repository origin/master
      Seen branch in repository origin/sprint/g2.2
      Seen 4 remote branches
      Starting with all the branches: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision a8b7d3421db68823b071ca74f269210718929406 (origin/sprint/g2.2)]
      Ignoring Branch origin/sprint/g2.2(AnyObjectId[a8b7d3421db68823b071ca74f269210718929406]) because it doesn't match branch specifier
      Ignoring Revision a8b7d3421db68823b071ca74f269210718929406 () because we don't care about any of the branches that point to it
      After branch filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)]
      After non-tip filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)]
      Removing what's already been built: {}
      After filtering out what's already been built: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)]
      Multiple candidate revisions
      Scheduling another build to catch up with NotifyCommitTest3
      Checking out Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)
      First time build. Skipping changelog.
      Description set: origin/bugfix/S14.02/stash-jenkins-test, 6fa2f3f32e94997c84c9a49b36c6346565ce8851
      Finished: SUCCESS
      

      Build #2 - ignores commit built in #1 and does the same job:

      Started by an SCM change
      [EnvInject] - Loading node environment variables.
      Building remotely on ch06bl09.mgmt.lmc.cz in workspace /srv/jenkins/workspace/NotifyCommitTest3@2
      Using strategy: Default
      Cloning the remote Git repository
      Cloning repository ssh://git@stash.int.lmc.cz:7999/rec/g2.git
      Fetching upstream changes from ssh://git@stash.int.lmc.cz:7999/rec/g2.git
      Fetching upstream changes from ssh://git@stash.int.lmc.cz:7999/rec/g2.git
      getCandidateRevisions(false,null,,,null,remoteUrls=[ssh://git@stash.int.lmc.cz:7999/rec/g2.git],buildsByBranchName={},lastBuild=null]) considering branches to build
      Seen branch in repository origin/bugfix/S14.02/stash-jenkins-test
      Seen branch in repository origin/feature/S14.02/stash-jenkins-test
      Seen branch in repository origin/master
      Seen branch in repository origin/sprint/g2.2
      Seen 4 remote branches
      Starting with all the branches: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test), Revision a8b7d3421db68823b071ca74f269210718929406 (origin/sprint/g2.2)]
      Ignoring Branch origin/sprint/g2.2(AnyObjectId[a8b7d3421db68823b071ca74f269210718929406]) because it doesn't match branch specifier
      Ignoring Revision a8b7d3421db68823b071ca74f269210718929406 () because we don't care about any of the branches that point to it
      After branch filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      After non-tip filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      Removing what's already been built: {}
      After filtering out what's already been built: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      Multiple candidate revisions
      Scheduling another build to catch up with NotifyCommitTest3
      Checking out Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)
      Description set: origin/bugfix/S14.02/stash-jenkins-test, 6fa2f3f32e94997c84c9a49b36c6346565ce8851
      Finished: SUCCESS
      

      Build #3:

      Started by an SCM change
      [EnvInject] - Loading node environment variables.
      Building remotely on ch06bl09.mgmt.lmc.cz in workspace /srv/jenkins/workspace/NotifyCommitTest3
      Using strategy: Default
      Fetching changes from the remote Git repository
      Fetching upstream changes from ssh://git@stash.int.lmc.cz:7999/rec/g2.git
      getCandidateRevisions(false,null,,,null,remoteUrls=[ssh://git@stash.int.lmc.cz:7999/rec/g2.git],buildsByBranchName={},lastBuild=null]) considering branches to build
      Seen branch in repository origin/bugfix/S14.02/stash-jenkins-test
      Seen branch in repository origin/feature/S14.02/stash-jenkins-test
      Seen branch in repository origin/master
      Seen branch in repository origin/sprint/g2.2
      Seen 4 remote branches
      Starting with all the branches: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test), Revision a8b7d3421db68823b071ca74f269210718929406 (origin/sprint/g2.2)]
      Ignoring Branch origin/sprint/g2.2(AnyObjectId[a8b7d3421db68823b071ca74f269210718929406]) because it doesn't match branch specifier
      Ignoring Revision a8b7d3421db68823b071ca74f269210718929406 () because we don't care about any of the branches that point to it
      After branch filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      After non-tip filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      Removing what's already been built: {}
      After filtering out what's already been built: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      Multiple candidate revisions
      Scheduling another build to catch up with NotifyCommitTest3
      Checking out Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)
      First time build. Skipping changelog.
      Description set: origin/bugfix/S14.02/stash-jenkins-test, 6fa2f3f32e94997c84c9a49b36c6346565ce8851
      Finished: SUCCESS
      

      Build #4 - skips the already-built-commit for the first time:

      Started by an SCM change
      [EnvInject] - Loading node environment variables.
      Building remotely on ch06bl09.mgmt.lmc.cz in workspace /srv/jenkins/workspace/NotifyCommitTest3
      Using strategy: Default
      Last Built Revision: Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)
      Fetching changes from the remote Git repository
      Fetching upstream changes from ssh://git@stash.int.lmc.cz:7999/rec/g2.git
      getCandidateRevisions(false,null,,,null,remoteUrls=[ssh://git@stash.int.lmc.cz:7999/rec/g2.git],buildsByBranchName={origin/bugfix/S14.02/stash-jenkins-test=Build #3 of Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)},lastBuild=Build #3 of Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)]) considering branches to build
      Seen branch in repository origin/bugfix/S14.02/stash-jenkins-test
      Seen branch in repository origin/feature/S14.02/stash-jenkins-test
      Seen branch in repository origin/master
      Seen branch in repository origin/sprint/g2.2
      Seen 4 remote branches
      Starting with all the branches: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test), Revision a8b7d3421db68823b071ca74f269210718929406 (origin/sprint/g2.2)]
      Ignoring Branch origin/sprint/g2.2(AnyObjectId[a8b7d3421db68823b071ca74f269210718929406]) because it doesn't match branch specifier
      Ignoring Revision a8b7d3421db68823b071ca74f269210718929406 () because we don't care about any of the branches that point to it
      After branch filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      After non-tip filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      Removing what's already been built: {origin/bugfix/S14.02/stash-jenkins-test=Build #3 of Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)}
      After filtering out what's already been built: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      Multiple candidate revisions
      Scheduling another build to catch up with NotifyCommitTest3
      Checking out Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master)
      First time build. Skipping changelog.
      Description set: origin/master, 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c
      Finished: SUCCESS
      

      Build #5:

      Started by an SCM change
      [EnvInject] - Loading node environment variables.
      Building remotely on ch06bl09.mgmt.lmc.cz in workspace /srv/jenkins/workspace/NotifyCommitTest3@2
      Using strategy: Default
      Last Built Revision: Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)
      Fetching changes from the remote Git repository
      Fetching upstream changes from ssh://git@stash.int.lmc.cz:7999/rec/g2.git
      getCandidateRevisions(false,null,,,null,remoteUrls=[ssh://git@stash.int.lmc.cz:7999/rec/g2.git],buildsByBranchName={origin/bugfix/S14.02/stash-jenkins-test=Build #3 of Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)},lastBuild=Build #3 of Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)]) considering branches to build
      Seen branch in repository origin/bugfix/S14.02/stash-jenkins-test
      Seen branch in repository origin/feature/S14.02/stash-jenkins-test
      Seen branch in repository origin/master
      Seen branch in repository origin/sprint/g2.2
      Seen 4 remote branches
      Starting with all the branches: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test), Revision a8b7d3421db68823b071ca74f269210718929406 (origin/sprint/g2.2)]
      Ignoring Branch origin/sprint/g2.2(AnyObjectId[a8b7d3421db68823b071ca74f269210718929406]) because it doesn't match branch specifier
      Ignoring Revision a8b7d3421db68823b071ca74f269210718929406 () because we don't care about any of the branches that point to it
      After branch filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      After non-tip filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      Removing what's already been built: {origin/bugfix/S14.02/stash-jenkins-test=Build #3 of Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)}
      After filtering out what's already been built: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      Multiple candidate revisions
      Scheduling another build to catch up with NotifyCommitTest3
      Checking out Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master)
      Description set: origin/master, 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c
      Finished: SUCCESS
      

      Build #6:

      Started by an SCM change
      [EnvInject] - Loading node environment variables.
      Building remotely on ch06bl09.mgmt.lmc.cz in workspace /srv/jenkins/workspace/NotifyCommitTest3
      Using strategy: Default
      Last Built Revision: Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master)
      Fetching changes from the remote Git repository
      Fetching upstream changes from ssh://git@stash.int.lmc.cz:7999/rec/g2.git
      getCandidateRevisions(false,null,,,null,remoteUrls=[ssh://git@stash.int.lmc.cz:7999/rec/g2.git],buildsByBranchName={origin/master=Build #5 of Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), origin/bugfix/S14.02/stash-jenkins-test=Build #3 of Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)},lastBuild=Build #5 of Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master)]) considering branches to build
      Seen branch in repository origin/bugfix/S14.02/stash-jenkins-test
      Seen branch in repository origin/feature/S14.02/stash-jenkins-test
      Seen branch in repository origin/master
      Seen branch in repository origin/sprint/g2.2
      Seen 4 remote branches
      Starting with all the branches: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test), Revision a8b7d3421db68823b071ca74f269210718929406 (origin/sprint/g2.2)]
      Ignoring Branch origin/sprint/g2.2(AnyObjectId[a8b7d3421db68823b071ca74f269210718929406]) because it doesn't match branch specifier
      Ignoring Revision a8b7d3421db68823b071ca74f269210718929406 () because we don't care about any of the branches that point to it
      After branch filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)]
      After non-tip filtering: [Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test), Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)]
      Removing what's already been built: {origin/master=Build #5 of Revision 7c98dcefea27ba90f5dc64710fdcd9f128f5ab5c (origin/master), origin/bugfix/S14.02/stash-jenkins-test=Build #3 of Revision 6fa2f3f32e94997c84c9a49b36c6346565ce8851 (origin/bugfix/S14.02/stash-jenkins-test)}
      After filtering out what's already been built: [Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)]
      Checking out Revision 549bbb10e97a90b1f26db59529ba861797771ccc (origin/feature/S14.02/stash-jenkins-test)
      First time build. Skipping changelog.
      Description set: origin/feature/S14.02/stash-jenkins-test, 549bbb10e97a90b1f26db59529ba861797771ccc
      Finished: SUCCESS
      

        Attachments

          Activity

          Hide
          ladoe00 . . added a comment -

          For us, it seems to happen almost everyday. It would be very nice if this issue could be fixed

          Show
          ladoe00 . . added a comment - For us, it seems to happen almost everyday. It would be very nice if this issue could be fixed
          Hide
          dengste David Engster added a comment - - edited

          I saw the same thing and came to the same conclusion, namely that the build data should either be saved earlier, or the build must be triggered later. I've created a patch to do the former and made a pull request (see https://github.com/jenkinsci/git-plugin/pull/238). It also seems to me that JENKINS-18588 is a duplicate of this bug.

          Show
          dengste David Engster added a comment - - edited I saw the same thing and came to the same conclusion, namely that the build data should either be saved earlier, or the build must be triggered later. I've created a patch to do the former and made a pull request (see https://github.com/jenkinsci/git-plugin/pull/238 ). It also seems to me that JENKINS-18588 is a duplicate of this bug.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Nicolas De Loof
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          http://jenkins-ci.org/commit/git-plugin/cf964ea9474b1436dfcc7706ac62505ff93119dd
          Log:
          [FIXED JENKINS-21464] save current Build in BuildData before re-scheduling job

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/cf964ea9474b1436dfcc7706ac62505ff93119dd Log: [FIXED JENKINS-21464] save current Build in BuildData before re-scheduling job
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Nicolas De Loof
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          http://jenkins-ci.org/commit/git-plugin/70b7c8d4bebcd85c3e5df8bf8c4b85dae679032a
          Log:
          [FIXED JENKINS-21464] save current Build in BuildData before re-scheduling job

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/70b7c8d4bebcd85c3e5df8bf8c4b85dae679032a Log: [FIXED JENKINS-21464] save current Build in BuildData before re-scheduling job
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Nicolas De Loof
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          http://jenkins-ci.org/commit/git-plugin/8e367245cdc03c3801263045283ac08182faf631
          Log:
          [FIXED JENKINS-21464] save current Build in BuildData before re-scheduling job

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/8e367245cdc03c3801263045283ac08182faf631 Log: [FIXED JENKINS-21464] save current Build in BuildData before re-scheduling job
          Hide
          sdetweil sam detweiler added a comment -

          what version is this available in? our Git Plugin is 2.2.1, our jenkins version is 1.554.2.2

          Show
          sdetweil sam detweiler added a comment - what version is this available in? our Git Plugin is 2.2.1, our jenkins version is 1.554.2.2
          Hide
          markewaite Mark Waite added a comment -

          The change is included in git client plugin 2.2.7 per the changelog on the wiki page

          Show
          markewaite Mark Waite added a comment - The change is included in git client plugin 2.2.7 per the changelog on the wiki page
          Hide
          markewaite Mark Waite added a comment -

          Sorry, that's git plugin 2.2.7, not git client plugin 2.2.7. The link I embedded points to the git plugin wiki page, but my words didn't match my link.

          Show
          markewaite Mark Waite added a comment - Sorry, that's git plugin 2.2.7, not git client plugin 2.2.7. The link I embedded points to the git plugin wiki page, but my words didn't match my link.
          Hide
          moshe_zvi Moshe Zvi added a comment -

          Still happening to me:
          git plugin 2.2.7, git client plugin 1.11.0.
          The error I get is actually:
          > git rev-parse refs/remotes/origin/origin/master^

          {commit}

          # timeout=10
          Multiple candidate revisions
          Scheduling another build to catch up with create-databag

          Any ideas?

          Show
          moshe_zvi Moshe Zvi added a comment - Still happening to me: git plugin 2.2.7, git client plugin 1.11.0. The error I get is actually: > git rev-parse refs/remotes/origin/origin/master^ {commit} # timeout=10 Multiple candidate revisions Scheduling another build to catch up with create-databag Any ideas?
          Hide
          sdetweil sam detweiler added a comment -

          Also still happening for us as well.
          git plugin 2.2.7, client 1.10.2

          Show
          sdetweil sam detweiler added a comment - Also still happening for us as well. git plugin 2.2.7, client 1.10.2
          Hide
          markewaite Mark Waite added a comment -

          Moshe Zvi the git rev-parse command being used in your case seems to include an extra "origin/" in the reference it is trying to parse. If I execute:

          git rev-parse refs/remotes/origin/origin/master^{commit} 
          

          in my repository, it reports an ambiguous argument to rev-parse.

          If I execute

          git rev-parse refs/remotes/origin/master^{commit} 
          

          it behaves correctly and finds a single candidate revision.

          Can you search your job definition looking for something which might introduce that extra "origin/" into the argument to "git rev-parse"?

          Show
          markewaite Mark Waite added a comment - Moshe Zvi the git rev-parse command being used in your case seems to include an extra "origin/" in the reference it is trying to parse. If I execute: git rev-parse refs/remotes/origin/origin/master^{commit} in my repository, it reports an ambiguous argument to rev-parse. If I execute git rev-parse refs/remotes/origin/master^{commit} it behaves correctly and finds a single candidate revision. Can you search your job definition looking for something which might introduce that extra "origin/" into the argument to "git rev-parse"?
          Hide
          moshe_zvi Moshe Zvi added a comment -

          @Mark, The only thing I can think of is the Branch Specifier in Jenkins, which is set to 'origin/master'. I believe this is the correct configuration, and in any case it doesn't work with just 'master'.
          When I was testing this particular job, I used a dedicated branch (i.e. not master), and the configuration 'origin/BRANCH_NAME' worked perfectly. I also didn't get the infinite loop.
          Could it be the plugin adds an extra 'origin' specifically when we use the master branch?

          Show
          moshe_zvi Moshe Zvi added a comment - @Mark, The only thing I can think of is the Branch Specifier in Jenkins, which is set to 'origin/master'. I believe this is the correct configuration, and in any case it doesn't work with just 'master'. When I was testing this particular job, I used a dedicated branch (i.e. not master), and the configuration 'origin/BRANCH_NAME' worked perfectly. I also didn't get the infinite loop. Could it be the plugin adds an extra 'origin' specifically when we use the master branch?
          Hide
          moshe_zvi Moshe Zvi added a comment -

          Mark Waite One more thing when I used the explicit 'remotes/origin/master', it disambiguated and ran correctly. Maybe it's a git thing.

          Show
          moshe_zvi Moshe Zvi added a comment - Mark Waite One more thing when I used the explicit 'remotes/origin/master', it disambiguated and ran correctly. Maybe it's a git thing.
          Hide
          g76r Greg Greg added a comment -

          Hi.

          I think I encountered the same issue (or a close one) and found a reproduction mean and a workaround:

          Reproduction mean:

          • need a jenkins project with */master branch specifier on a git repo with a branch named master
          • clone a git repository with a branch named master
          • create a new branch named origin/master (instead of master) and push it to the origin repo
          • wait for jenkins to start a build on master (not origin/master) either by polling or triggered by a webhook on commit on master (not origin/master) branch
          • now you can even remove the misspelled origin/master branch
          • trigger a jenkins build and infinite builds begin

          Workaround 1:

          • use master as branch specifier rather than */master

          Workaround 2:

          • force recloning the jenkins repo by triggering a build with wipe out & force clone option turned on
          • then you can even remove the wipe out option

          Hope that will help fixing the issue or coping with it...

          Show
          g76r Greg Greg added a comment - Hi. I think I encountered the same issue (or a close one) and found a reproduction mean and a workaround: Reproduction mean: need a jenkins project with */master branch specifier on a git repo with a branch named master clone a git repository with a branch named master create a new branch named origin/master (instead of master) and push it to the origin repo wait for jenkins to start a build on master (not origin/master) either by polling or triggered by a webhook on commit on master (not origin/master) branch now you can even remove the misspelled origin/master branch trigger a jenkins build and infinite builds begin Workaround 1: use master as branch specifier rather than */master Workaround 2: force recloning the jenkins repo by triggering a build with wipe out & force clone option turned on then you can even remove the wipe out option Hope that will help fixing the issue or coping with it...
          Hide
          fk_ fk_ added a comment -

          Why this was closed? The issue is still here, versions are
          Jenkins ver. 1.625.1
          Git Parameter Plug-In 0.4.0
          Git plugin 2.4.2
          Git server plugin 1.6
          GitHub API Plugin 1.72.1
          GitHub plugin 1.17.1
          GitHub Pull Request Builder 1.31.1
          Gitlab Hook Plugin 1.4.1.1
          multiple-scms@0.3

          Show
          fk_ fk_ added a comment - Why this was closed? The issue is still here, versions are Jenkins ver. 1.625.1 Git Parameter Plug-In 0.4.0 Git plugin 2.4.2 Git server plugin 1.6 GitHub API Plugin 1.72.1 GitHub plugin 1.17.1 GitHub Pull Request Builder 1.31.1 Gitlab Hook Plugin 1.4.1.1 multiple-scms@0.3
          Hide
          fk_ fk_ added a comment -

          Actually we found that we had a branch named 'origin/branch' instead of 'branch' and drove jenkins a nuts. After removing 'origin/branch' and purging workspace everything worked fine.

          Show
          fk_ fk_ added a comment - Actually we found that we had a branch named 'origin/branch' instead of 'branch' and drove jenkins a nuts. After removing 'origin/branch' and purging workspace everything worked fine.
          Hide
          markewaite Mark Waite added a comment -

          Won't fix the case where a branch exists named "origin/master" (which can be referenced as origin/origin/master) because that fix seems very likely to break many cases of branch name matching on which users depend.

          Show
          markewaite Mark Waite added a comment - Won't fix the case where a branch exists named "origin/master" (which can be referenced as origin/origin/master) because that fix seems very likely to break many cases of branch name matching on which users depend.
          Hide
          petrjanata petrjanata added a comment -

          I also observed similar behavior. When 'Branch Specifier' was not unique, then checkout actually triggered another build of the same job.

          This was strange, because the job didn't have Poll SCM Build Trigger checked. Actually this job had none of the Build Trigger mechanisms checked and was intended to be scheduled only manually.

          The first build was executed manually with Branch Specifier = branch123 and log contained:

           

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

          At that point a new unwanted build of this job was scheduled and waited in the Build Queue. When it started, the log contained:

           

          Started by an SCM change
          Building on master

          The initial problem was non-unique Branch Specifier. I will fix it by using the longer remote ref refs/remotes/origin/branch123.

          Mark Waite Could you consider changing the plugin to fail instead of triggering a new build in case non-unique revision is required to be checked out? At least in case when job does not allow Poll SCM Build Trigger.


          What was the job for and how this issue happened?

          The job uses Jenkins job SCM Git to checkout a branch (say branch123) with Clean before checkout. Then in Execute shell build step it modifies some files in the checkout (pom.xmls), commits, tags (as tag123-rc1) and pushes. The local branch123 HEAD points to the same commit as tag123-rc1. So far so good.

          Then developers push more changes into branch123 and we want to release as tag123-rc2. So we run our job again. Git-plugin does cleanup on the repository in the job workspace, but this leaves the local branch123 intact, so it still points to the same revision as tag123-rc1. (so other viable solution would be to wipe workspace between builds)

          Plugin then fetches refs from remote and refs/remotes/origin/branch123 now points to the new commits made by developers. Git-plugin compares revision of both references that contain substring branch123. Since the remote branch moved, both refs now point to different revisions. Git-plugin reacts to this with 'Multiple candidate revisions' message and triggers a new build.

          In case both refs point to the same revision (no changes were made on the branch between two builds), then Git-plugin checks out the single revision and no build is triggered.

           > git config remote.origin.url ssh://XXX.git # timeout=10
          Cleaning workspace
           > git rev-parse --verify HEAD # timeout=10
          Resetting working tree
           > git reset --hard # timeout=10
           > git clean -fdx # timeout=10
           > git submodule foreach --recursive git reset --hard # timeout=10
           > git submodule foreach --recursive git clean -fdx # timeout=10
          Fetching upstream changes from ssh://XXX.git
           > git --version # timeout=10
          using GIT_SSH to set credentials XXX
           > git fetch --tags --progress ssh://XXX.git +refs/heads/*:refs/remotes/origin/*
           > git rev-parse branch123^{commit} # timeout=10
           > git rev-parse refs/remotes/origin/branch123^{commit} # timeout=10
          Multiple candidate revisions
          Scheduling another build to catch up with My_Build_Job_Name

           

          Show
          petrjanata petrjanata added a comment - I also observed similar behavior. When 'Branch Specifier' was not unique, then checkout actually triggered another build of the same job. This was strange, because the job didn't have Poll SCM Build Trigger checked. Actually this job had none of the Build Trigger mechanisms checked and was intended to be scheduled only manually. The first build was executed manually with Branch Specifier = branch123 and log contained:   > git rev-parse branch123^{commit} # timeout=10 > git rev-parse refs/remotes/origin/branch123^{commit} # timeout=10 Multiple candidate revisions Scheduling another build to catch up with My_Build_Job_Name At that point a new unwanted build of this job was scheduled and waited in the Build Queue. When it started, the log contained:   Started by an SCM change Building on master The initial problem was non-unique Branch Specifier. I will fix it by using the longer remote ref refs/remotes/origin/branch123. Mark Waite Could you consider changing the plugin to fail instead of triggering a new build in case non-unique revision is required to be checked out? At least in case when job does not allow Poll SCM Build Trigger. What was the job for and how this issue happened? The job uses Jenkins job SCM Git to checkout a branch (say branch123) with Clean before checkout. Then in Execute shell build step it modifies some files in the checkout (pom.xmls), commits, tags (as tag123-rc1) and pushes. The local branch123 HEAD points to the same commit as tag123-rc1. So far so good. Then developers push more changes into branch123 and we want to release as tag123-rc2. So we run our job again. Git-plugin does cleanup on the repository in the job workspace, but this leaves the local branch123 intact, so it still points to the same revision as tag123-rc1. (so other viable solution would be to wipe workspace between builds) Plugin then fetches refs from remote and refs/remotes/origin/branch123 now points to the new commits made by developers. Git-plugin compares revision of both references that contain substring branch123. Since the remote branch moved, both refs now point to different revisions. Git-plugin reacts to this with 'Multiple candidate revisions' message and triggers a new build. In case both refs point to the same revision (no changes were made on the branch between two builds), then Git-plugin checks out the single revision and no build is triggered. > git config remote.origin.url ssh: //XXX.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 > git submodule foreach --recursive git reset --hard # timeout=10 > git submodule foreach --recursive git clean -fdx # timeout=10 Fetching upstream changes from ssh: //XXX.git > git --version # timeout=10 using GIT_SSH to set credentials XXX > git fetch --tags --progress ssh: //XXX.git +refs/heads/*:refs/remotes/origin/* > git rev-parse branch123^{commit} # timeout=10 > git rev-parse refs/remotes/origin/branch123^{commit} # timeout=10 Multiple candidate revisions Scheduling another build to catch up with My_Build_Job_Name  
          Hide
          markewaite Mark Waite added a comment - - edited

          petrjanata you asked:

          Could you consider changing the plugin to fail instead of triggering a new build in case non-unique revision is required to be checked out? At least in case when job does not allow Poll SCM Build Trigger.

          No, I'm not willing to change the plugin to fail instead of triggering a new build in case a non-unique revision is required to be checked out. I believe that will break more use cases than it fixes and will introduce an incompatibility which will cause problems for many users.

          Show
          markewaite Mark Waite added a comment - - edited petrjanata you asked: Could you consider changing the plugin to fail instead of triggering a new build in case non-unique revision is required to be checked out? At least in case when job does not allow Poll SCM Build Trigger. No, I'm not willing to change the plugin to fail instead of triggering a new build in case a non-unique revision is required to be checked out. I believe that will break more use cases than it fixes and will introduce an incompatibility which will cause problems for many users.

            People

            • Assignee:
              markewaite Mark Waite
              Reporter:
              minarikv Vojta Minarik
            • Votes:
              8 Vote for this issue
              Watchers:
              22 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: