bhaalsen / gitmerger Goto Github PK

One of our older tickets caused a semi-wrong action for the automerge...a different repository with a longer branch name (already merged, but left as remote) has been changed as a result.

Ticket JRA-123 was closed, and branch JRA-1239 was accepted as match. This shouldn't happen.

Looks like #1 is broken:

Found 2 branches matching 'JRA-1234', cannot decide which one to merge: GitMerger.RepositoryHandling.GitRepositoryBranch, GitMerger.RepositoryHandling.GitRepositoryBranch

This should show the actual branch name; not the type name.

Once the Jira WebHook triggers a merge, fields such as the Upstream Branch or Disable Merge are set in stone; they are not updated after the initial wait is over.

Jira Comments are limited to 32767 characters, so very verbose merge failures may not make it:

GitMerger.IssueTracking.JiraBasicRestClient: Request to 'http://jira-server/rest/api/2/issue/JRA-1234/comment' apparently failed: The remote server returned an error: (400) Bad Request.
{"errorMessages":[],"errors":{"comment":"The entered text is too long. It exceeds the allowed limit of 32767 characters."}}

This should probably be one or more of those things:

• Limit the number of charaters for output (each of them) and truncate them either way (best is probably to keep the front parts?)
• Limit the total length of the comment and try to re-trim parts if necessary
• Retry with a shorter/different comment when it fails (because right now, only the log file has the error)

Just like #6, we don't consider the actual close status (again). This is checked before the wait time, but not afterwards. #6 added the check for "Disable Automerge", but we should probably do all the checks again (in case the ticket was closed prematurely and shoud not merge yet)

GitHub Pull Requests provide a "Revert" button at the end that create another Pull Request that does the inverse. It would probably be nice to provide a link with the issue comment that does this (or rather, shows a HTML form requiring additional confirmation before the revert is attempted). May supersede #2, but may also take longer to implement (especially with failure cases).

This should also add another issue comment with infos about how to get the changes merged correctly. https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html describes why this is the case; and why a simple additional merge won't work.

Steps to reproduce:

1. Create a branch to be merged
2. Merge the branch by hand, but leave the remote branch
3. Trigger a merge

Since the Merge has no effect, the following amend (GitRepositoryManager.cs line 133) changes the manually merged commit, and thus fails the push afterwards (even after resetting and re-pulling, since the result is the same there).

In case the automerge worked, but the change itself is not correct; provide some manual instructions on what to do (especially with the -m parent-number switch).

In case there are multiple matching branches, nothing happens. At least not from a Jira perspective, because the merge request is simply ignored.

Instead, it should still add a comment to the Jira issue that the automatic merge could not decide on which one to take.

Work is done in ticket JRA-1337, but for collaboration purposes another branch JRA-1337_review has been pushed as well. As result, the merger could not decide which one to use (and due to #1 nobody was informed).

Extend the configuration to provide a list of namespaces (that is, for example, review in review/JRA-1337 or private in private/JRA-1337) to be excluded, or even make it a regex (so partial matches without a namespace; such as a _review or _testing are possible).