feat(gitprovider/gitlab): Support for squash merge and fast forward

[aslafy-z]

Currently, gitprovider.PullRequest.MergeCommitSHA is set only from glMR.MergeCommitSHA by the GitLab provider.

This works for merge strategies that create a merge commit, but it breaks for repositories configured to use fast-forward merges without a merge commit: in those cases, the commit information stays empty even though the merge request is successfully merged.

GitLab’s API exposes three relevant fields on merge requests:

• merge_commit_sha: SHA of the merge commit (when one exists).
• squash_commit_sha: SHA of the squash commit.
• sha: SHA of the head commit in the source branch.

According to the documentation, a squashed merge is supposed to populate squash_commit_sha, and (depending on merge method) may or may not create a merge commit. However, there are known inconsistencies in GitLab’s current implementation:

• Squash merges currently populate merge_commit_sha with the squashed commit and leave squash_commit_sha unset in the webhook payloads.
• There is ongoing work to backfill and correctly populate squash_commit_sha and to fix related webhook behavior.

See:

• https://gitlab.com/gitlab-org/gitlab/-/issues/415449
• https://gitlab.com/gitlab-org/gitlab/-/issues/294257
• https://gitlab.com/groups/gitlab-org/-/epics/20145

To handle both the current behavior and the intended future behavior, this PR updates convertGitlabMR to compute an “effective merge commit SHA” only when the merge request is in the merged state, using the following precedence:

1. glMR.MergeCommitSHA if it is set
   • Covers today’s GitLab behavior for classic merge commits, and for squash merges where GitLab currently puts the squash commit into merge_commit_sha.
2. glMR.SquashCommitSHA if MergeCommitSHA is empty but SquashCommitSHA is set
   • Covers the future / intended behavior and fast-forward-with-squash cases where there is no merge commit but a squash commit exists.
3. glMR.SHA if both MergeCommitSHA and SquashCommitSHA are empty
   • Covers fast-forward-without-squash, where no merge or squash commit is created and the target branch is advanced to the source tip.

For unmerged merge requests, MergeCommitSHA remains empty.

This makes the GitLab provider resilient to both current and future GitLab implementations while ensuring MergeCommitSHA accurately reflects the commit that actually landed on the target branch for merged requests.

[netlify]

✅ Deploy Preview for docs-kargo-io ready!

Name	Link
🔨 Latest commit	c9133f9
🔍 Latest deploy log	https://app.netlify.com/projects/docs-kargo-io/deploys/693c27624ac4f80009b036cc
😎 Deploy Preview	https://deploy-preview-5454.docs.kargo.io
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[krancour]

@fuskovic because of your familiarity with all the webhook receivers, I'd like you to look at this PR as well, please. Please consult the GitLab docs and/or experiment a bit with their API to verify this is indeed how things work on their end.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.36%. Comparing base (41252b5) to head (c9133f9).
⚠️ Report is 226 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5454      +/-   ##
==========================================
+ Coverage   55.35%   55.36%   +0.01%     
==========================================
  Files         430      430              
  Lines       31851    31861      +10     
==========================================
+ Hits        17631    17641      +10     
  Misses      13214    13214              
  Partials     1006     1006              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[fuskovic]

I think some additional context in the comments for the future-proofing behavior could be useful.

[fuskovic]

LGTM, deferring to @krancour for merge

[krancour]

I'm going to close this in favor of #5581 since that one essentially adds this feature for all Git hosting providers.

We'll be mindful of the possibility that there may be bits of GitLab-specific stuff in this PR that's worth porting over to #5581.