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

          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 .

          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

          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!

          pixman20 added a comment -

          Would love to see this added.  In my case, I keep seeing builds break with "No changes".

          As mentioned before, this is caused by either a) a bad merge conflict resolution, or b) someone modifying unrelated code during the resolution.

          Unfortunately, this would be a breaking change as it would change the behavior and it's very likely that some people would want to keep it the old way.

          I think the change for this plugin would be to support modifying the changelog method via another plugin or some setting that's part of this plugin.

          I imagine this working similar to how you can select other git options, such as using a different branch for determining the changelog.

           

          pixman20 added a comment - Would love to see this added.  In my case, I keep seeing builds break with "No changes". As mentioned before, this is caused by either a) a bad merge conflict resolution, or b) someone modifying unrelated code during the resolution. Unfortunately, this would be a breaking change as it would change the behavior and it's very likely that some people would want to keep it the old way. I think the change for this plugin would be to support modifying the changelog method via another plugin or some setting that's part of this plugin. I imagine this working similar to how you can select other git options, such as using a different branch for determining the changelog.  

          Josiah Eubank added a comment -

          Josiah Eubank added a comment - The line in question is now  https://github.com/jenkinsci/git-client-plugin/blob/master/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L972

          Alexey Milov added a comment -

          Where is a link to the patch (although mixed with another one) in issue:

           https://issues.jenkins-ci.org/browse/JENKINS-32320

          that fixes problem with merge commit not appearing by providing option to call whatchanged with -m option, and corresponding change to Jgit calling. I believe the patch can be used to solve this issue after separation and updating to current version of plugins.

          Alexey Milov added a comment - Where is a link to the patch (although mixed with another one) in issue:   https://issues.jenkins-ci.org/browse/JENKINS-32320 that fixes problem with merge commit not appearing by providing option to call whatchanged with -m option, and corresponding change to Jgit calling. I believe the patch can be used to solve this issue after separation and updating to current version of plugins.

          Xuezhong Yan added a comment - - edited

          I had the same issue. GitLab Merge Commit is not displayed in Jenkins "changes". 

          We create feature/user-story branch from "integration" branch, then creating a merge request and merging to "integration", we want the build "changes" in Jenkins looks exactly same as it is in GitLab "Commits".

           

          Xuezhong Yan added a comment - - edited I had the same issue. GitLab Merge Commit is not displayed in Jenkins "changes".  We create feature/user-story branch from "integration" branch, then creating a merge request and merging to "integration", we want the build "changes" in Jenkins looks exactly same as it is in GitLab "Commits".  

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

              Created:
              Updated: