Skip to content

feat: Add squash merge support to git-merge-pr promotion step#5581

Open
bobdoah wants to merge 5 commits intoakuity:mainfrom
bobdoah:main
Open

feat: Add squash merge support to git-merge-pr promotion step#5581
bobdoah wants to merge 5 commits intoakuity:mainfrom
bobdoah:main

Conversation

@bobdoah
Copy link

@bobdoah bobdoah commented Jan 14, 2026

Adds a new 'mergeMethod' configuration option to the git-merge-pr promotion step that allows users to specify the merge strategy when merging pull requests.

This fulfils the feature request I opened in #5580.

@bobdoah bobdoah requested review from a team as code owners January 14, 2026 20:17
@netlify
Copy link

netlify bot commented Jan 14, 2026

Deploy Preview for docs-kargo-io ready!

Name Link
🔨 Latest commit cfb87c2
🔍 Latest deploy log https://app.netlify.com/projects/docs-kargo-io/deploys/696fc22c08b4c10008b739a1
😎 Deploy Preview https://deploy-preview-5581.docs.kargo.io
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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

Copy link
Contributor

@hiddeco hiddeco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for implementing this, and I think it is a fair feature request. I made a couple of suggestions here and there.

My primary concern, other than what's commented, is that we silently ignore merge methods not supported by the selected provider. I think we should either:

  1. Return an error when a user specifies a merge method that the provider doesn't support
  2. Log a warning so users understand their preference wasn't honored

I'd lean toward option 1, as it's typically better to fail explicitly than to silently do something different from what the user requested.

@codecov
Copy link

codecov bot commented Jan 15, 2026

Codecov Report

❌ Patch coverage is 70.32967% with 27 lines in your changes missing coverage. Please review.
✅ Project coverage is 56.34%. Comparing base (9c066ee) to head (cfb87c2).
⚠️ Report is 17 commits behind head on main.

Files with missing lines Patch % Lines
pkg/gitprovider/azure/azure.go 34.48% 19 Missing ⚠️
pkg/gitprovider/bitbucket/bitbucket.go 28.57% 5 Missing ⚠️
pkg/gitprovider/gitea/gitea.go 90.47% 2 Missing ⚠️
pkg/gitprovider/gitprovider.go 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5581      +/-   ##
==========================================
+ Coverage   56.29%   56.34%   +0.04%     
==========================================
  Files         426      426              
  Lines       32262    32308      +46     
==========================================
+ Hits        18163    18204      +41     
- Misses      13045    13050       +5     
  Partials     1054     1054              

☔ 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.

@bobdoah
Copy link
Author

bobdoah commented Jan 15, 2026

Thanks for implementing this, and I think it is a fair feature request. I made a couple of suggestions here and there.

My primary concern, other than what's commented, is that we silently ignore merge methods not supported by the selected provider. I think we should either:

  1. Return an error when a user specifies a merge method that the provider doesn't support
  2. Log a warning so users understand their preference wasn't honored

I'd lean toward option 1, as it's typically better to fail explicitly than to silently do something different from what the user requested.

Hey, you're welcome and thanks for the comments.

I had considered either of those two options. I didn't see how I might go about option 2. I guess I thought it would fail how it currently does. I can see how option 1 is preferable, and help users.

Hopefully my latest changes address your comments. Happy to change/reword anything if you've got any other preferences!

@bobdoah bobdoah force-pushed the main branch 5 times, most recently from f6f4c62 to c65237b Compare January 19, 2026 21:34
@bobdoah bobdoah requested a review from hiddeco January 19, 2026 21:35
@bobdoah
Copy link
Author

bobdoah commented Jan 19, 2026

I've made some further changes as the code coverage drop was flagged as a failure.

@hiddeco hiddeco added kind/enhancement An entirely new feature area/controller Affects the (main) controller labels Jan 20, 2026
bobdoah and others added 5 commits January 20, 2026 17:57
Adds a new 'mergeMethod' configuration option to the git-merge-pr
promotion step that allows users to specify the merge strategy when
merging pull requests.

Signed-off-by: Robert Williams <bobdoah@users.noreply.github.com>
Signed-off-by: Robert Williams <1266467+bobdoah@users.noreply.github.com>
Signed-off-by: Robert Williams <1266467+bobdoah@users.noreply.github.com>
Signed-off-by: Robert Williams <1266467+bobdoah@users.noreply.github.com>
Signed-off-by: Robert Williams <1266467+bobdoah@users.noreply.github.com>
@hiddeco hiddeco added this to the v1.10.0 milestone Jan 20, 2026
@hiddeco
Copy link
Contributor

hiddeco commented Jan 20, 2026

I think this is best combined with #5454 as I suspect the resolved SHA for GitLab will otherwise be wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/controller Affects the (main) controller kind/enhancement An entirely new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants