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

SCM polling with GIT creates Spurious Builds with "No Changes"

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      I see many builds when pushes to non-master branches (I'm only pulling from the master branch). The build is triggered by SCM change but the master branch has the same ID. Here is a discussion on StackOverflow where others are encountering the same problem (http://stackoverflow.com/questions/5784329/how-can-i-make-jenkins-ci-with-git-trigger-on-pushes-to-master).

          [JENKINS-9596] SCM polling with GIT creates Spurious Builds with "No Changes"

          Peter Kline added a comment - - edited

          We are also seeing very similar behavior where periodically we have builds for no reason and it skews our build metrics:

          build 209: d7a260b81c84795efe999920c41f2bd7425573f5 - 1 change
          build 210: d1da70414962b568e7b5b244560bd49a6fcc6b9c - 1 change
          build 211: d1da70414962b568e7b5b244560bd49a6fcc6b9c - No Changes
          build 212: 4d642c3dd2cbcb7f120021dabcf28cb684c34f6e - 1 Change
          build 213: 4d642c3dd2cbcb7f120021dabcf28cb684c34f6e - No Changes

          Git Polling log 212:
          Started on Jun 3, 2011 11:20:24 AM
          Using strategy: Default
          [poll] Last Build : #211
          [poll] Last Built Revision: Revision d1da70414962b568e7b5b244560bd49a6fcc6b9c (remotes/origin/main_int)
          Fetching changes from the remote Git repositories
          Fetching upstream changes from git@thoroughbred:flt/root.git
          Polling for changes in
          Done. Took 1.1 sec
          Changes found

          Git Polling Log 213:
          Started on Jun 3, 2011 11:25:24 AM
          Using strategy: Default
          [poll] Last Build : #212
          [poll] Last Built Revision: Revision d1da70414962b568e7b5b244560bd49a6fcc6b9c (remotes/origin/main_int)
          Fetching changes from the remote Git repositories
          Fetching upstream changes from git@thoroughbred:flt/root.git
          Polling for changes in
          Done. Took 0.97 sec
          Changes found

          Env Info:
          Jenkins: 1.413
          Git Plugin: 1.1.9
          Local Git repository using submodules

          Config block for Git

          <scm class="hudson.plugins.git.GitSCM">
          <configVersion>2</configVersion>
          <userRemoteConfigs>
          <hudson.plugins.git.UserRemoteConfig>
          <name>origin</name>
          <refspec>+refs/heads/main_int:refs/remotes/origin/main_int</refspec>
          <url>git@thoroughbred:flt/root.git</url>
          </hudson.plugins.git.UserRemoteConfig>
          </userRemoteConfigs>
          <branches>
          <hudson.plugins.git.BranchSpec>
          <name>remotes/origin/main_int</name>
          </hudson.plugins.git.BranchSpec>
          </branches>
          <recursiveSubmodules>true</recursiveSubmodules>
          <doGenerateSubmoduleConfigurations>false</doGenerateSubmoduleConfigurations>
          <authorOrCommitter>true</authorOrCommitter>
          <clean>false</clean>
          <wipeOutWorkspace>true</wipeOutWorkspace>
          <pruneBranches>false</pruneBranches>
          <buildChooser class="hudson.plugins.git.util.DefaultBuildChooser"/>
          <gitTool>Default</gitTool>
          <submoduleCfg class="list"/>
          <relativeTargetDir></relativeTargetDir>
          <excludedRegions></excludedRegions>
          <excludedUsers></excludedUsers>
          <gitConfigName></gitConfigName>
          <gitConfigEmail></gitConfigEmail>
          <skipTag>false</skipTag>
          <scmName></scmName>
          </scm>

          Peter Kline added a comment - - edited We are also seeing very similar behavior where periodically we have builds for no reason and it skews our build metrics: build 209: d7a260b81c84795efe999920c41f2bd7425573f5 - 1 change build 210: d1da70414962b568e7b5b244560bd49a6fcc6b9c - 1 change build 211: d1da70414962b568e7b5b244560bd49a6fcc6b9c - No Changes build 212: 4d642c3dd2cbcb7f120021dabcf28cb684c34f6e - 1 Change build 213: 4d642c3dd2cbcb7f120021dabcf28cb684c34f6e - No Changes Git Polling log 212: Started on Jun 3, 2011 11:20:24 AM Using strategy: Default [poll] Last Build : #211 [poll] Last Built Revision: Revision d1da70414962b568e7b5b244560bd49a6fcc6b9c (remotes/origin/main_int) Fetching changes from the remote Git repositories Fetching upstream changes from git@thoroughbred:flt/root.git Polling for changes in Done. Took 1.1 sec Changes found Git Polling Log 213: Started on Jun 3, 2011 11:25:24 AM Using strategy: Default [poll] Last Build : #212 [poll] Last Built Revision: Revision d1da70414962b568e7b5b244560bd49a6fcc6b9c (remotes/origin/main_int) Fetching changes from the remote Git repositories Fetching upstream changes from git@thoroughbred:flt/root.git Polling for changes in Done. Took 0.97 sec Changes found Env Info: Jenkins: 1.413 Git Plugin: 1.1.9 Local Git repository using submodules Config block for Git <scm class="hudson.plugins.git.GitSCM"> <configVersion>2</configVersion> <userRemoteConfigs> <hudson.plugins.git.UserRemoteConfig> <name>origin</name> <refspec>+refs/heads/main_int:refs/remotes/origin/main_int</refspec> <url>git@thoroughbred:flt/root.git</url> </hudson.plugins.git.UserRemoteConfig> </userRemoteConfigs> <branches> <hudson.plugins.git.BranchSpec> <name>remotes/origin/main_int</name> </hudson.plugins.git.BranchSpec> </branches> <recursiveSubmodules>true</recursiveSubmodules> <doGenerateSubmoduleConfigurations>false</doGenerateSubmoduleConfigurations> <authorOrCommitter>true</authorOrCommitter> <clean>false</clean> <wipeOutWorkspace>true</wipeOutWorkspace> <pruneBranches>false</pruneBranches> <buildChooser class="hudson.plugins.git.util.DefaultBuildChooser"/> <gitTool>Default</gitTool> <submoduleCfg class="list"/> <relativeTargetDir></relativeTargetDir> <excludedRegions></excludedRegions> <excludedUsers></excludedUsers> <gitConfigName></gitConfigName> <gitConfigEmail></gitConfigEmail> <skipTag>false</skipTag> <scmName></scmName> </scm>

          Olaf Lenz added a comment -

          I'm now again referring to the behavior in the case of the triggered build.

          Unfortunately, github doesn't allow to specify when the webhook is fired - it will always be fired when something is pushed to the repo, no matter what branch. This is what creates the spurious builds.

          A simple solution on the Jenkins side of things would be to make sure that the project is not built unnecessarily by simply causing a poll after the trigger is fired, i.e. by simply using the mechanism that checks for changes when polling the SCM also in the case of the trigger.

          Shouldn't that be simple?

          Olaf Lenz added a comment - I'm now again referring to the behavior in the case of the triggered build. Unfortunately, github doesn't allow to specify when the webhook is fired - it will always be fired when something is pushed to the repo, no matter what branch. This is what creates the spurious builds. A simple solution on the Jenkins side of things would be to make sure that the project is not built unnecessarily by simply causing a poll after the trigger is fired, i.e. by simply using the mechanism that checks for changes when polling the SCM also in the case of the trigger. Shouldn't that be simple?

          Peter Kline added a comment -

          This is no longer an issue for us after using the method by Kohsuke:
          http://kohsuke.org/2011/12/01/polling-must-die-triggering-jenkins-builds-from-a-git-hook/

          Peter Kline added a comment - This is no longer an issue for us after using the method by Kohsuke: http://kohsuke.org/2011/12/01/polling-must-die-triggering-jenkins-builds-from-a-git-hook/

          evernat added a comment -

          So we can close this issue, given the last comment with a solution?

          evernat added a comment - So we can close this issue, given the last comment with a solution?

          Olaf Lenz added a comment -

          I think that we can, yes. I am using Kohsuke's method since a few months, and since then there is no more trouble.

          Olaf Lenz added a comment - I think that we can, yes. I am using Kohsuke's method since a few months, and since then there is no more trouble.

          evernat added a comment -

          ok, thanks

          evernat added a comment - ok, thanks

          Hi,

          We also have this same issue. The Kohsuke workaround would not really be efficient for us as we got a pretty big team, which would make jenkins build permanently.

          I do not really agree with this ticket closing because even if Kohsuke found a workaround, the real feature is still not working.

          Would it be possible to re-open this ticket ?
          Maybe I could give a hand to resolve this in Jenkins, with some help

          Thanks,
          Regards,

          Maxime Schneider-Dufeutrelle

          Edit : For information, this only happens with Multiple SCMs jobs, not with jobs configured for a simpel Git repo.

          Maxime Schneider-Dufeutrelle added a comment - - edited Hi, We also have this same issue. The Kohsuke workaround would not really be efficient for us as we got a pretty big team, which would make jenkins build permanently. I do not really agree with this ticket closing because even if Kohsuke found a workaround, the real feature is still not working. Would it be possible to re-open this ticket ? Maybe I could give a hand to resolve this in Jenkins, with some help Thanks, Regards, Maxime Schneider-Dufeutrelle Edit : For information, this only happens with Multiple SCMs jobs, not with jobs configured for a simpel Git repo.

          Kurt Preston added a comment -

          Currently encountering the issue when using the 'Inverse' choosing strategy for a single git repo.

          Kurt Preston added a comment - Currently encountering the issue when using the 'Inverse' choosing strategy for a single git repo.

          trejkaz added a comment -

          I thought I was seeing this issue, but now that I have looked at it a bit closer, I'm not sure, so I will describe what I'm seeing and then someone can decide whether it's a new issue.

          1. We saw a build started which was described like "Compile #2001 Build failed (Started by an SCM change)"
          2. On actually going to Jenkins, it says "Revision: 57751" and also "No changes", and "Started by an SCM change", which is contradictory at best.
          3. On looking at what's in that revision, it turns out there were actually changes.

          trejkaz added a comment - I thought I was seeing this issue, but now that I have looked at it a bit closer, I'm not sure, so I will describe what I'm seeing and then someone can decide whether it's a new issue. 1. We saw a build started which was described like "Compile #2001 Build failed (Started by an SCM change)" 2. On actually going to Jenkins, it says "Revision: 57751" and also "No changes", and "Started by an SCM change", which is contradictory at best. 3. On looking at what's in that revision, it turns out there were actually changes.

          I haven't seen this issue in a long time. Is it fixed now?

          Christian Höltje added a comment - I haven't seen this issue in a long time. Is it fixed now?

            Unassigned Unassigned
            cscalfani Charles Scalfani
            Votes:
            18 Vote for this issue
            Watchers:
            20 Start watching this issue

              Created:
              Updated: