-
Notifications
You must be signed in to change notification settings - Fork 302
feat(gitprovider/gitlab): Support for squash merge and fast forward #5454
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for docs-kargo-io ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@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. |
Signed-off-by: GitHub <[email protected]>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5454 +/- ##
==========================================
+ Coverage 55.07% 55.12% +0.05%
==========================================
Files 426 426
Lines 31528 31566 +38
==========================================
+ Hits 17363 17401 +38
Misses 13161 13161
Partials 1004 1004 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Currently,
gitprovider.PullRequest.MergeCommitSHAis set only fromglMR.MergeCommitSHAby 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:merge_commit_shawith the squashed commit and leavesquash_commit_shaunset in the webhook payloads.squash_commit_shaand to fix related webhook behavior.See:
To handle both the current behavior and the intended future behavior, this PR updates
convertGitlabMRto compute an “effective merge commit SHA” only when the merge request is in themergedstate, using the following precedence:glMR.MergeCommitSHAif it is setmerge_commit_sha.glMR.SquashCommitSHAifMergeCommitSHAis empty butSquashCommitSHAis setglMR.SHAif bothMergeCommitSHAandSquashCommitSHAare emptyFor unmerged merge requests,
MergeCommitSHAremains empty.This makes the GitLab provider resilient to both current and future GitLab implementations while ensuring
MergeCommitSHAaccurately reflects the commit that actually landed on the target branch for merged requests.