[go: up one dir, main page]

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-merge merge_request.target_branch_sha
  • head_commit_sha set to merge_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.

Proposal

We've identified that merge request links are also missing for running pipelines on MRs running on generated merge request refs. While less critical than the main issue, fixing this would align pipeline behavior with source branch commits, which correctly display associated MRs before merging.

Implementation Approach

  1. Create dedicated storage for generated MR ref commits
    • Add a new table to store commits generated for pipeline execution or merge operations
    • Preferred over modifying existing diff types since no new diff is created
    • only needed columns are merge_request_id, commit_sha
  2. Store data during ref creation
    • Capture commit relationships in CreateRefService when refs are generated
    • Future enhancement: extend to MergeToRefService commits (not required for current customer issue)
Edited by 🤖 GitLab Bot 🤖