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"

          Charles Scalfani created issue -
          Andrew Bayer made changes -
          Assignee New: Andrew Bayer [ abayer ]

          Andrew Bayer added a comment -

          I'm not sure this is something that can be dealt with from the git plugin's side of things - if you use polling rather than post-receive hooks, you'll be just fine, though. But if you want to use the post-receive hook, you'll need to refine its behavior down to only call out to Jenkins when a specific branch is pushed.

          Andrew Bayer added a comment - I'm not sure this is something that can be dealt with from the git plugin's side of things - if you use polling rather than post-receive hooks, you'll be just fine, though. But if you want to use the post-receive hook, you'll need to refine its behavior down to only call out to Jenkins when a specific branch is pushed.

          I am using SCM polling (frankly, don't know about post-receive hooks). I'm pulling only the master branch and get builds when the master has NOT changed.

          Charles Scalfani added a comment - I am using SCM polling (frankly, don't know about post-receive hooks). I'm pulling only the master branch and get builds when the master has NOT changed.

          Andrew Bayer added a comment -

          Could you attach your job's config.xml?

          Andrew Bayer added a comment - Could you attach your job's config.xml?

          Here is the job's config.xml.

          Charles Scalfani added a comment - Here is the job's config.xml.
          Charles Scalfani made changes -
          Attachment New: config.xml [ 20437 ]

          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?
          Uwe Stuehler made changes -
          Link New: This issue is related to JENKINS-10131 [ JENKINS-10131 ]

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

              Created:
              Updated: