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

          Sergio Roldan added a comment - - edited

          I guess this is not the same issue when using Jenkins Workflow Plugin.
          I can see this git polling log:

          Started on Oct 15, 2015 9:08:29 AM
          Using strategy: Default
          [poll] Last Built Revision: Revision 74072d171ab432943380ab42ab14950a1149bb04 (refs/remotes/origin/develop)
           > git rev-parse --is-inside-work-tree # timeout=10
          Fetching changes from the remote Git repositories
           > git config remote.origin.url git@github.com:organization/project.git # timeout=10
          Fetching upstream changes from git@github.com:organization/project.git
           > git --version # timeout=10
          using GIT_SSH to set credentials deploy user on github
           > git -c core.askpass=true fetch --tags --progress git@github.com:organization/project.git +refs/heads/*:refs/remotes/origin/*
          Polling for changes in
           > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
           > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
           > git log --full-history --no-abbrev --format=raw -M -m --raw 74072d171ab432943380ab42ab14950a1149bb04..bb7c4edad7fa934f5b67cdd7a24f8c42fd9f899f # timeout=10
          Ignored commit bb7c4edad7fa934f5b67cdd7a24f8c42fd9f899f: Found excluded author: deployuser
          Ignored commit 3f417d8e3ae6e9c7e024a41d719cb08e7dba594f: Found excluded author: deployuser
          Using strategy: Default
          [poll] Last Built Revision: Revision 74072d171ab432943380ab42ab14950a1149bb04 (refs/remotes/origin/develop)
          using GIT_SSH to set credentials deploy user on github
           > git --version # timeout=10
           > git -c core.askpass=true ls-remote -h git@github.com:organization/project.git # timeout=10
          Found 7 remote heads on git@github.com:organization/project.git
          [poll] Latest remote head revision on refs/heads/develop is: bb7c4edad7fa934f5b67cdd7a24f8c42fd9f899f
          Done. Took 2.5 sec
          Changes found
          

          It is using git "user.name" because I have also tested with random users (deploy ssh keys not related with any github user) setting an arbitrary user.name property.
          As you can see, 'deployuser' is detected and excluded in the first polling, but later, changes are detected and build is fired.

          Using same polling configuration from a free-style job works like a charm.

          Sergio Roldan added a comment - - edited I guess this is not the same issue when using Jenkins Workflow Plugin. I can see this git polling log: Started on Oct 15, 2015 9:08:29 AM Using strategy: Default [poll] Last Built Revision: Revision 74072d171ab432943380ab42ab14950a1149bb04 (refs/remotes/origin/develop) > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repositories > git config remote.origin.url git@github.com:organization/project.git # timeout=10 Fetching upstream changes from git@github.com:organization/project.git > git --version # timeout=10 using GIT_SSH to set credentials deploy user on github > git -c core.askpass= true fetch --tags --progress git@github.com:organization/project.git +refs/heads/*:refs/remotes/origin/* Polling for changes in > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10 > git log --full-history --no-abbrev --format=raw -M -m --raw 74072d171ab432943380ab42ab14950a1149bb04..bb7c4edad7fa934f5b67cdd7a24f8c42fd9f899f # timeout=10 Ignored commit bb7c4edad7fa934f5b67cdd7a24f8c42fd9f899f: Found excluded author: deployuser Ignored commit 3f417d8e3ae6e9c7e024a41d719cb08e7dba594f: Found excluded author: deployuser Using strategy: Default [poll] Last Built Revision: Revision 74072d171ab432943380ab42ab14950a1149bb04 (refs/remotes/origin/develop) using GIT_SSH to set credentials deploy user on github > git --version # timeout=10 > git -c core.askpass= true ls-remote -h git@github.com:organization/project.git # timeout=10 Found 7 remote heads on git@github.com:organization/project.git [poll] Latest remote head revision on refs/heads/develop is: bb7c4edad7fa934f5b67cdd7a24f8c42fd9f899f Done. Took 2.5 sec Changes found It is using git "user.name" because I have also tested with random users (deploy ssh keys not related with any github user) setting an arbitrary user.name property. As you can see, 'deployuser' is detected and excluded in the first polling, but later, changes are detected and build is fired. Using same polling configuration from a free-style job works like a charm.

          Tuyen Lieu added a comment -

          I tested again with additional "Use commit author in changelog" behaviour. It returned my author name < Lieu, Tuyen>

           @Override
              public Boolean isRevExcluded(GitSCM scm, GitClient git, GitChangeSet commit, TaskListener listener, BuildData buildData) {
                  String author = commit.getAuthorName();
                  if (getExcludedUsersNormalized().contains(author)) {
                      // If the author is an excluded user, don't count this entry as a change
                      listener.getLogger().println("Ignored commit " + commit.getCommitId() + ": Found excluded author: " + author);
                      return true;
                  }
          
                  return null;
              }
          

          As you can see from the method above, without the "Use commit author in changelog", it will return author name.
          In my case, it returns author name with/without this option, which seems quite strange. I guess Stash may notify some funny metadata.

          Have you tried to put some breakpoints at the above method in hudson.plugsin.git.extensions.impl.UserExclusion ?

          Tuyen Lieu added a comment - I tested again with additional "Use commit author in changelog" behaviour. It returned my author name < Lieu, Tuyen> @Override public Boolean isRevExcluded(GitSCM scm, GitClient git, GitChangeSet commit, TaskListener listener, BuildData buildData) { String author = commit.getAuthorName(); if (getExcludedUsersNormalized().contains(author)) { // If the author is an excluded user, don't count this entry as a change listener.getLogger().println( "Ignored commit " + commit.getCommitId() + ": Found excluded author: " + author); return true ; } return null ; } As you can see from the method above, without the "Use commit author in changelog", it will return author name. In my case, it returns author name with/without this option, which seems quite strange. I guess Stash may notify some funny metadata. Have you tried to put some breakpoints at the above method in hudson.plugsin.git.extensions.impl.UserExclusion ?

          Mark Waite added a comment -

          sergiorc your comment that it does not work for the workflow case is a very different case than the case described in this bug. I'm not sure the workflow use of the git plugin enables all the configuration options available in the git plugin, especially things that are as complicated as excluding commits by user. I think you'd be better served by reporting a separate bug, rather than just including a comment in this bug report.

          Mark Waite added a comment - sergiorc your comment that it does not work for the workflow case is a very different case than the case described in this bug. I'm not sure the workflow use of the git plugin enables all the configuration options available in the git plugin, especially things that are as complicated as excluding commits by user. I think you'd be better served by reporting a separate bug, rather than just including a comment in this bug report.

          Andy Wang added a comment -

          Hitting the issue and the workaround doesn't work for me.
          Using Jenkins ver. 1.635; Git plugin 2.4.0; Gerrit-trigger plugin 2.17.0
          I set both ignore commit from certain users and in certain paths. But neither worked.
          How do people deal with it when it relates to change version number in certain file and don't want that to trigger a build?

          Andy Wang added a comment - Hitting the issue and the workaround doesn't work for me. Using Jenkins ver. 1.635; Git plugin 2.4.0; Gerrit-trigger plugin 2.17.0 I set both ignore commit from certain users and in certain paths. But neither worked. How do people deal with it when it relates to change version number in certain file and don't want that to trigger a build?

          Mark Waite added a comment -

          winnerwbx you might consider creating a small test job which does not use the Gerrit-trigger plugin, just to see if you can confirm that you're using the correct syntax for excluding by user name. Once it is functioning in the simple job, then try that same syntax with your job which uses the Gerrit-trigger plugin.

          Mark Waite added a comment - winnerwbx you might consider creating a small test job which does not use the Gerrit-trigger plugin, just to see if you can confirm that you're using the correct syntax for excluding by user name. Once it is functioning in the simple job, then try that same syntax with your job which uses the Gerrit-trigger plugin.

          Andy Wang added a comment -

          Mark Waite I tested on a small job without Gerrit-trigger plugin. And the result showed that the polling ignores are well functioning. I tested on all three ignore commit options( by user name, by commit message and by file path), they all worked no matter if the "Force polling using workspace" checked or not.
          But once added Gerrit-trigger plugin, it didn't work. The job triggers on all commits despite the polling ignore settings.

          Andy Wang added a comment - Mark Waite I tested on a small job without Gerrit-trigger plugin. And the result showed that the polling ignores are well functioning. I tested on all three ignore commit options( by user name, by commit message and by file path), they all worked no matter if the "Force polling using workspace" checked or not. But once added Gerrit-trigger plugin, it didn't work. The job triggers on all commits despite the polling ignore settings.

          Darth Vader added a comment -

          I believe this is related to JENKINS-25048. The proposed solution and I believe it makes sense is that the external trigger (web hook) triggers a poll not a build. Like that, all the custom rules for users, included/excluded regions would be honored.

          Darth Vader added a comment - I believe this is related to JENKINS-25048 . The proposed solution and I believe it makes sense is that the external trigger (web hook) triggers a poll not a build. Like that, all the custom rules for users, included/excluded regions would be honored.

          Yan Corneille added a comment -

          Is there another way to do such things ? I'm in the exact same situation, trying to ignore Jenkins own commits due to continuous delivery. I wanted to use exclusions in pipelines because that's the way I did it with regular jenkins jobs, but if there is another way to achieve this goal, it's more than welcome.
          I tried to check on GIT_* env variables, but they're not yet accessible.
          Des anyone have a workaround ?

          Yan Corneille added a comment - Is there another way to do such things ? I'm in the exact same situation, trying to ignore Jenkins own commits due to continuous delivery. I wanted to use exclusions in pipelines because that's the way I did it with regular jenkins jobs, but if there is another way to achieve this goal, it's more than welcome. I tried to check on GIT_* env variables, but they're not yet accessible. Des anyone have a workaround ?

          I am seeing the same behavior, but I don't have the gerrit-triger plugin installed.

           

          I am attempting to use a post-commit hook to only build on 2 included regions of my repo.

          Robert Everson added a comment - I am seeing the same behavior, but I don't have the gerrit-triger plugin installed.   I am attempting to use a post-commit hook to only build on 2 included regions of my repo.

          We have the same behavior, but I don't have the gerrit-triger plugin installed.

          We use TFS Service Hooks for external SCM polling.

          Christian Häussler added a comment - We have the same behavior, but I don't have the gerrit-triger plugin installed. We use TFS Service Hooks for external SCM polling.

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

              Created:
              Updated: