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") {
              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.


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