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

Gerrit trigger caused git plugin polling to not ignore commit from certain users

      For our continuos Integration we are using maven-release-plugin. For which we would like to ignore commits from Jenkins user which is incrementing artifact version and doing commit.
      With Polling SCM and using "Polling ignores commit from certain users" to ignore commits by Jenkins user which is not working as expected and going to infinite loop.

          [JENKINS-20607] Gerrit trigger caused git plugin polling to not ignore commit from certain users

          venu 1456 created issue -

          Having the same issue. Also, the "Polling ignores commits in certain paths" feature is not working as well.

          Carl von Buelow added a comment - Having the same issue. Also, the "Polling ignores commits in certain paths" feature is not working as well.

          julio rincon added a comment -

          Same here: user excludes, region includes/excludes not working.

          julio rincon added a comment - Same here: user excludes, region includes/excludes not working.

          Owen Jacobson added a comment -

          Workaround: enable the "force polling using workspace" additional behaviour.

          The underlying cause is an overly optimistic implementation of "fast" polling (by comparing only the last built commit and the current branch tip via git ls-remote). "Fast" polling doesn't download commits until after a build decision has been made, which means there's no way for the commit inspection rules to evaluate.

          I've got [a pull request](https://github.com/jenkinsci/git-plugin/pull/181) open that fixes the problem by making commit inspecting rules force the slow path; the "force polling using workspace" additional behaviour does the same thing.

          Owen Jacobson added a comment - Workaround: enable the "force polling using workspace" additional behaviour. The underlying cause is an overly optimistic implementation of "fast" polling (by comparing only the last built commit and the current branch tip via git ls-remote ). "Fast" polling doesn't download commits until after a build decision has been made, which means there's no way for the commit inspection rules to evaluate. I've got [a pull request] ( https://github.com/jenkinsci/git-plugin/pull/181 ) open that fixes the problem by making commit inspecting rules force the slow path; the "force polling using workspace" additional behaviour does the same thing.
          Owen Jacobson made changes -
          Link New: This issue is related to JENKINS-10131 [ JENKINS-10131 ]

          venu 1456 added a comment -

          @Owen, I tried "Force Polling using workspace" option which didnt work in my case. I see that your pull request is not yet merged,once done i'll try it again.

          venu 1456 added a comment - @Owen, I tried "Force Polling using workspace" option which didnt work in my case. I see that your pull request is not yet merged,once done i'll try it again.

          Hitting this issue and the suggested workaround works for us.

          Jenkins ver. 1.546
          Jenkins Git plugin 2.0.1

          We use excluded regions as well as excluded users heavily.

          Gautam Jayaprakash added a comment - Hitting this issue and the suggested workaround works for us. Jenkins ver. 1.546 Jenkins Git plugin 2.0.1 We use excluded regions as well as excluded users heavily.

          Onur Ozardic added a comment -

          I also hit the issue, the workaround does not work for me, too.
          I am using Jenkins ver. 1.551 with Git Plugin 2.01. I upgraded from 1.543 and 2.0 which it was not working too.

          Onur Ozardic added a comment - I also hit the issue, the workaround does not work for me, too. I am using Jenkins ver. 1.551 with Git Plugin 2.01. I upgraded from 1.543 and 2.0 which it was not working too.

          Karla Jacobsen added a comment - - edited

          I also thought that this workaround was not working, but my mistake was actually that my regex was invalid. I found the problem when I checked my Jenkins log files looking for something else. I wanted to mention it in case anyone else was making the same mistake. I was trying to use something like "somedirectory/**" (because that what I'm used to using with a lot of Java based applications), but the correct regex would be "somedirectory/.*".

          Karla Jacobsen added a comment - - edited I also thought that this workaround was not working, but my mistake was actually that my regex was invalid. I found the problem when I checked my Jenkins log files looking for something else. I wanted to mention it in case anyone else was making the same mistake. I was trying to use something like "somedirectory/**" (because that what I'm used to using with a lot of Java based applications), but the correct regex would be "somedirectory/.*".

          Michael Niestegge added a comment - - edited

          Same here. Workaround does not work for me. Does it matter what order the additional behaviors have?

          My concrete problem:

          2 branches: A and B
          Job is parameterized so I can tell which branch to build.
          Job scans both branches (by origin/**) every hour to check for changes.
          Jenkins raises the build number within the pom files.
          Commits by Jenkins user should be ignored and not cause the job to run.

          When the last build was in branch A and changes in branch B (by scanning origin/**) are detected, the build for branch B gets kicked off correctly. Unfortunately also changes in branch A (raised build number by jenkins)are detected an d another build gets scheduled, leaving this message in the log:

          Multiple candidate revisions
          Scheduling another build to catch up with (BUILD) my faulty job

          From that point on, the job switches between branch A and B every time and is scheduling the other branch to get build every time causing an endless loop.

          Michael Niestegge added a comment - - edited Same here. Workaround does not work for me. Does it matter what order the additional behaviors have? My concrete problem: 2 branches: A and B Job is parameterized so I can tell which branch to build. Job scans both branches (by origin/**) every hour to check for changes. Jenkins raises the build number within the pom files. Commits by Jenkins user should be ignored and not cause the job to run. When the last build was in branch A and changes in branch B (by scanning origin/**) are detected, the build for branch B gets kicked off correctly. Unfortunately also changes in branch A (raised build number by jenkins)are detected an d another build gets scheduled, leaving this message in the log: Multiple candidate revisions Scheduling another build to catch up with (BUILD) my faulty job From that point on, the job switches between branch A and B every time and is scheduling the other branch to get build every time causing an endless loop.

            Unassigned Unassigned
            venu1456 venu 1456
            Votes:
            22 Vote for this issue
            Watchers:
            27 Start watching this issue

              Created:
              Updated: