Missing MR links on rebased merge train commits (FF merge)
Summary
We recently adopted semilinear FF merge trains in one of our projects. we use changelogs to generate changelogs for our releases. we now realized that sometimes the merge_request
link is missing in our releases.
The reason is simple enough, when merge trains rebase the commits, they do not update the commits referenced in the original MR. so if you happen to be second car in the pipeline, the commit that lands in main is not the same id as the commit referenced by MR. Hence no backlink.
Steps to reproduce
- create two MR, add them both to a merge train
What is the current bug behavior?
- the commits linked in the first MR are the commits that landed in main, as they never got rebased
- the commits linked in the second MR are not in history anymore
- the commits that landed from the second MR have no back-link to the original MR.
as a result, the changelog api cannot see the second MR.
What is the expected correct behavior?
the commits in the second MR point to the commits in history
alternatively: the back-links to the original MR exist in rebased commits.
Possible fixes
Add a new type post_merge
to MergeRequestDiff
. Then, when an MR is merged, create the post-merge diff with
-
start_commit_sha
set to the pre-mergemerge_request.target_branch_sha
-
head_commit_sha
set tomerge_request.merged_commit_sha
The MergeService#commit
method should have access to both of the above values. The service could be slightly tweaked to forward them to MergeRequest::PostMergeService
, which could be responsible for triggering the diff generation.
If overhead of storing it for all merges is a concern, we can restrict it to non-squashed merges that included a server-side rebase. At the moment, that means non-squashed semi-linear and fast-forward merge trains.