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

option to treat merge commiters as regular commiters

      Note: This request initially posted on stackoverflow: http://stackoverflow.com/q/20101472/937363
      ---------------------------------------------------------------------------------------------------------------------------

      Users A and B each make modifications (on different feature branches) to a particular repo.

      User A merges changes into staging branch. Jenkins builds the staging branch, and succeeds.

      User C (release manager for User B team) merges User B's changes into staging branch. However, something in the merge goes wrong and isn't noticed, such as a conflict that wasn't resolved properly.

      Jenkins builds the staging branch, and fails because of the bad merge.

      Users A and B are notified of the build failure, because their code was part of the merge, even though their changes were not at fault. User C never gets a failure notice, even though his bad merge was what broke the build.

      There should be a way to:

      1. Cause Jenkins to treat merge commits as changes? (There is the very real possibility that code will actually be modified during a merge!)
      2. Notify User C (as the merge committer) along with users A and B?
        We are using the Git and Email-ext plugins for Jenkins.
        • I think this would be handled automatically by the previous
      3. Set option to only show the merge committer in the case of a merge
        • There are examples where we have a platform merge team who merges in from one stable branch to another. In that case, it is always the merger's responsibility to handle it correctly, so no other committers should be notified

          [JENKINS-28907] option to treat merge commiters as regular commiters

          Matt Gately created issue -
          Matt Gately made changes -
          Description Original: Note: This request initially posted on stackoverflow: http://stackoverflow.com/q/20101472/937363

          Users A and B each make modifications (on different feature branches) to a particular repo.

          User A merges changes into staging branch. Jenkins builds the staging branch, and succeeds.

          User C (release manager for User B team) merges User B's changes into staging branch. However, something in the merge goes wrong and isn't noticed, such as a conflict that wasn't resolved properly.

          Jenkins builds the staging branch, and fails because of the bad merge.

          Users A and B are notified of the build failure, because their code was part of the merge, even though their changes were not at fault. User C never gets a failure notice, even though his bad merge was what broke the build.

          There should be a way to:

          # Cause Jenkins to treat merge commits as changes? (There is the very real possibility that code will actually be modified during a merge!)
          # Notify User C (as the merge committer) along with users A and B?
          We are using the Git and Email-ext plugins for Jenkins.
          #* I think this would be handled automatically by the previous
          # Set option to only show the merge committer in the case of a merge
          #* There are examples where we have a platform merge team who merges in from one stable branch to another. In that case, it is always the merger's responsibility to handle it correctly, so no other committers should be notified
          New: Note: This request initially posted on stackoverflow: http://stackoverflow.com/q/20101472/937363
          ---------------------------------------------------------------------------------------------------------------------------

          Users A and B each make modifications (on different feature branches) to a particular repo.

          User A merges changes into staging branch. Jenkins builds the staging branch, and succeeds.

          User C (release manager for User B team) merges User B's changes into staging branch. However, something in the merge goes wrong and isn't noticed, such as a conflict that wasn't resolved properly.

          Jenkins builds the staging branch, and fails because of the bad merge.

          Users A and B are notified of the build failure, because their code was part of the merge, even though their changes were not at fault. User C never gets a failure notice, even though his bad merge was what broke the build.

          There should be a way to:

          # Cause Jenkins to treat merge commits as changes? (There is the very real possibility that code will actually be modified during a merge!)
          # Notify User C (as the merge committer) along with users A and B?
          We are using the Git and Email-ext plugins for Jenkins.
          #* I think this would be handled automatically by the previous
          # Set option to only show the merge committer in the case of a merge
          #* There are examples where we have a platform merge team who merges in from one stable branch to another. In that case, it is always the merger's responsibility to handle it correctly, so no other committers should be notified

          Ben Lucato added a comment -

          At my workplace, this would be really useful for us.

          We have a workflow where only testers can merge changes, and therefore want to be the recipient of notifications. Because they aren't treated as committers we have use a couple of scripts that we've written to analyse the changelog to detect the merge committers.

          Ben Lucato added a comment - At my workplace, this would be really useful for us. We have a workflow where only testers can merge changes, and therefore want to be the recipient of notifications. Because they aren't treated as committers we have use a couple of scripts that we've written to analyse the changelog to detect the merge committers.

          Kurtis Miller added a comment -

          From a comment on the Stack Overflow post, it looks like the plugin uses git whatchanged, which skips merges. This is equivalent to git log --raw --no-merges, so this might be as simple as changing it to git log --raw.

          Note that the documentation for whatchanged discourages the use of whatchanged in favor of log.

          Kurtis Miller added a comment - From a comment on the Stack Overflow post, it looks like the plugin uses git whatchanged , which skips merges. This is equivalent to git log --raw --no-merges , so this might be as simple as changing it to git log --raw . Note that the documentation for whatchanged discourages the use of whatchanged in favor of log .
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 163771 ] New: JNJira + In-Review [ 181367 ]

          Bing Shiao added a comment -

          Bing Shiao added a comment - kurtismiller is correct. Looks like it can be done by making change in this line https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L837

          Mathew Sprehn added a comment -

          git whatchanged is still different. See this answer for more information: http://stackoverflow.com/questions/10022722/difference-between-git-log-and-git-whatchanged#answer-10023369

          Mathew Sprehn added a comment - git whatchanged is still different. See this answer for more information: http://stackoverflow.com/questions/10022722/difference-between-git-log-and-git-whatchanged#answer-10023369
          Mathew Sprehn made changes -
          Assignee Original: Nicolas De Loof [ ndeloof ] New: Mathew Sprehn [ matsprehn ]
          Mathew Sprehn made changes -
          Component/s New: git-client-plugin [ 17423 ]

          Kevin Burnett added a comment -

          we investigated this a bit. we found that the only difference between these two, for our repos, was that the git log included some extra commits due to it defaulting to "rev.always_show_header = 1".

          git whatchanged --no-merges --format="commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b"
          
          git log --raw --no-merges --format="commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b"
          

          there is a check in the git source code where it doesn't set rev.always_show_header to true when --diff-filter is used. so if we set diff filter to not actually filter (by including everything), the git whatchanged and git log commands return identical output for us.

          so the final equivalent git log command is this:

          git log --diff-filter=ACDMRTUXB --raw --no-merges --format="commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b"
          

          so, to include merge commits, we can simply remove the --no-merges from the git log, leaving us with:

          git log --diff-filter=ACDMRTUXB --raw --format="commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b"
          

          pull request at https://github.com/jenkinsci/git-client-plugin/pull/237 that uses this approach and adds merge commits!

          Kevin Burnett added a comment - we investigated this a bit. we found that the only difference between these two, for our repos, was that the git log included some extra commits due to it defaulting to "rev.always_show_header = 1". git whatchanged --no-merges --format= "commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b" git log --raw --no-merges --format= "commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b" there is a check in the git source code where it doesn't set rev.always_show_header to true when --diff-filter is used. so if we set diff filter to not actually filter (by including everything), the git whatchanged and git log commands return identical output for us. so the final equivalent git log command is this: git log --diff-filter=ACDMRTUXB --raw --no-merges --format= "commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b" so, to include merge commits, we can simply remove the --no-merges from the git log, leaving us with: git log --diff-filter=ACDMRTUXB --raw --format= "commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b" pull request at https://github.com/jenkinsci/git-client-plugin/pull/237 that uses this approach and adds merge commits!

            Unassigned Unassigned
            mbgately Matt Gately
            Votes:
            15 Vote for this issue
            Watchers:
            16 Start watching this issue

              Created:
              Updated: