19

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.

Is there 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.

Edit, several months later: Still having issues with this — even in a scenario where the person who did the merge did not introduce breaking changes, it would still be nice for them to be notified that the build succeeded (or failed).

Greg Bacon
  • 134,834
  • 32
  • 188
  • 245
GalacticCowboy
  • 11,663
  • 2
  • 41
  • 66
  • 3
    I encourage you to search their issue tracker, https://issues.jenkins-ci.org/secure/IssueNavigator.jspa, and if they don't have it, file it. – user3352495 Mar 09 '14 at 20:29
  • 3
    Internally Git plugin uses "git whatchanged" command which "is essentially the same as git-log but defaults to show the raw format diff output and to skip merges". So it's by design. – izzekil Jan 20 '15 at 16:42
  • 2
    I agree with @user3352495 about filing an issue with their [tracker](http://issues.jenkins-ci.org/secure/IssueNavigator.jspa?mode=hide&reset=true&jqlQuery=project+%3D+JENKINS+AND+status+in+%28Open%2C+%22In+Progress%22%2C+Reopened%29+AND+component+%3D+%27git-plugin%27). I am having the same issue. I searched the tracker and did not find a corresponding issue, so I created a [new issue](https://issues.jenkins-ci.org/browse/JENKINS-28907) myself. – mattgately Jun 15 '15 at 12:34

2 Answers2

2

You can try to force always no fast-forward merges (--no-ff option) and all merges will produce even a merge-commit (not only when there are conflicts).

It also produce a more readable and clear git log.

BTW check if you have the last version of the Jenkins Git plugin (they had issues in the past).

Community
  • 1
  • 1
Dario
  • 3,905
  • 2
  • 13
  • 27
-3

The problem with what you're describing is that you will end up with extra commits in your git history.

If user A and user B are making changes that need to eventually be merged, then, once merged, your git history should show you the SHAs for userA's and userB's changes.

If I'm inspecting the history after userC has merged userB's changes, then I really don't want to see an extra git commit telling me that userC has merged userB's commit - the latter is already present in the git history.

And if userC's merge is logged in the git history - how would it be logged? What would the diff look like?

I think the problem in the scenario you describe is that userC wasn't paying enough attention when merging to notice the merge error. Good software doesn't preclude the need to have competent developers.

Kal
  • 371
  • 2
  • 7