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

Multiple Git polling causes build to be triggered when all commits are excluded

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Minor Minor
    • core, git-plugin
    • None
    • RHEL 7.3, Jenkins 2.60.2, Git Plugin 3.4.0

      I've set up a pipeline project that is configured with "Pipeline script from SCM".
      The Poll SCM scheduled is set to each minute.
      "Branches to build" is set to "refs/remotes/origin/master" and I've also set up "Polling ignores commits from certain users".

      The repo that contains the Jenkinsfile is also the repo that contains the code.
      The Jenkinsfile begins with a stage like this:

      stage("checkout") {
          git([
              url: "https://github.com/${project}/${repoName}.git",
              poll: false
          ])
      }
      

      The build process is also pushing commits back to the repository, which is the same user I'm ignoring in the "Polling ignores commits from certain users".

      What happens is that after a build has finished, and the Jenkins server has pushed code back to the repo, the Git Poll Log still shows that a new build should be triggered:

       

      Using strategy: Default
      [poll] Last Built Revision: Revision 817962faa6ece5a2caf2c11bd14c097bff6e28d2 (refs/remotes/origin/master)
       > git rev-parse --is-inside-work-tree # timeout=10
      Fetching changes from the remote Git repositories
       > git config remote.origin.url https://github.com/project/repo.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
      Fetching upstream changes from https://github.com/project/repo.git
       > git --version # timeout=10
       > git fetch --tags --progress https://github.com/project/repo.git +refs/heads/*:refs/remotes/origin/*
      Polling for changes in
       > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
       > git rev-parse refs/remotes/origin/refs/heads/master^{commit} # timeout=10
       > git log --full-history --no-abbrev --format=raw -M -m 817962faa6ece5a2caf2c11bd14c097bff6e28d2..b7ff1e80ab7d10e8f0d45a90d2fed662933d70d0 # timeout=10
      Ignored commit b7ff1e80ab7d10e8f0d45a90d2fed662933d70d0: Found excluded author: jenkins-release-bot
      Ignored commit 7dfbaeade555c10f23cfffea9bb458bf69e53a3a: Found excluded author: jenkins-release-bot
      
      Using strategy: Default
      [poll] Last Built Revision: Revision 817962faa6ece5a2caf2c11bd14c097bff6e28d2 (refs/remotes/origin/master)
       > git ls-remote -h https://github.com/project/repo.git # timeout=10
      Found 1 remote heads on https://github.com/project/repo.git
      [poll] Latest remote head revision on refs/heads/master is: b7ff1e80ab7d10e8f0d45a90d2fed662933d70d0
      
      Done. Took 1.9 sec
      Changes found
      

      If you pay attention you should see that the two commits generated from the previous build are indeed excluded ("Found excluded author: jenkins-release-bot"), but then a new Poll entry ("git ls-remote") is started which triggers a new build.

      • Why is there two poll entries? I have only specified one polling schedule
      • Why is a new build triggered, when the log shows that the two commits are excluded?

      The result is that it will be an endless loop, as each build results in two commits which in turn trigger a new build.

       

          [JENKINS-46059] Multiple Git polling causes build to be triggered when all commits are excluded

          David Steinsland added a comment - - edited

          Some updates to this issue:

          • I've found that the second Git poll entry is caused by the git step in the Jenkinsfile. The pipeline project is correctly configured to ignore a certain user, but the polling scheme that the git step follows completely ignores these settings.
          • Setting the poll: false property to the git step seems to do nothing.
          • Same issue when using the checkout step instead

          Current workaround:

          • Ditch the git step entirely, and rely on a combination of cleanWs() (to start with an empty workspace) and sh 'git clone https://github.com/project/repo.git .' to fetch the code manually.

          David Steinsland added a comment - - edited Some updates to this issue: I've found that the second Git poll entry is caused by the  git step in the Jenkinsfile. The pipeline project is correctly configured to ignore a certain user, but the polling scheme that the  git step follows completely ignores these settings. Setting the poll: false property to the git step seems to do nothing. Same issue when using the checkout step instead Current workaround: Ditch the git step entirely, and rely on a combination of  cleanWs() (to start with an empty workspace) and sh 'git clone https://github.com/project/repo.git .' to fetch the code manually.

          Mark Waite added a comment -

          Resolving as duplicate of JENKINS-36195 so that conversation about the question remains in a single bug report.

          Mark Waite added a comment - Resolving as duplicate of JENKINS-36195 so that conversation about the question remains in a single bug report.

            Unassigned Unassigned
            davstein David Steinsland
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: