Add gpg signing for merge rebase and update by rebase#36701
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request adds GPG/SSH signing support for pull request operations that involve rebasing: merge-by-rebase and update-branch-by-rebase. Previously, commits created during these operations were not signed even when signing was configured, which is the issue reported in #36685.
Changes:
- Refactored commit signing logic into a reusable
addCommitSigningOptionshelper function - Applied signing to rebase operations in merge and update workflows
- Added integration test to verify commits are signed after update-by-rebase operation
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| services/pull/merge.go | Introduces addCommitSigningOptions helper function to centralize GPG/SSH signing configuration for git commands |
| services/pull/merge_squash.go | Refactored to use the new addCommitSigningOptions helper instead of inline signing logic |
| services/pull/merge_rebase.go | Added signing support to the commit amend operation in rebase fast-forward merge |
| services/pull/merge_prepare.go | Added signing support to the rebase command used when tracking branch is rebased onto base |
| tests/integration/gpg_ssh_git_test.go | Added comprehensive test case verifying commits are signed after update-by-rebase with appropriate signing configuration |
Comments suppressed due to low confidence (1)
services/pull/merge.go:454
- Inconsistent flag format: The codebase consistently uses
-S%sformat for GPG signing (see modules/git/repo_tree.go:52, services/repository/init.go:51, services/repository/files/temp_repo.go:299), but this line uses--gpg-sign=%s. While both formats are functionally equivalent in git, the code should maintain consistency with the existing convention.
cmd.AddOptionFormat("--gpg-sign=%s", signKey.KeyID)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
BTW @lunny i would recommend stop backporting so much and focus on getting 1.26 out, it's already due. Maybe make one last 1.25 release but then move forward please. |
|
I never see he has any plan. Till now, the 1.25.4 release issue is still open. Release: Publish Gitea 1.25.4 #36278 |
|
Yeah and this manual release process is too complex. Like 75% of those points can and should be automated. Release process should be triggered by the tag push, everything else can be triggered on CI, except maybe the blog post. |
Hm, too many security fix haven't been fixed/merged. |
|
Sure, security fixes are fine but instead of backporting so much, I think it's more important to have regular main branch releases, like every 3 months would be desirable, on a fixed an predictable schedule at least. The problem with the release branches is they are always lagging behind in many regards. We don't update dependencies in them so the dependencies become vulnerable over time. Better to have more frequent main branch releases to lessen that dependency problem. |
|
Last call @go-gitea/technical-oversight-committee |
* main: Repair duration display for bad stopped timestamps (go-gitea#37121) Add terraform state registry (go-gitea#36710) Add placeholder content for empty content page (go-gitea#37114) Improve control char rendering and escape button styling (go-gitea#37094) Add gpg signing for merge rebase and update by rebase (go-gitea#36701) Move package settings to package instead of being tied to version (go-gitea#37026) Merge some standalone Vite entries into index.js (go-gitea#37085) Update Nix flake (go-gitea#37110) [skip ci] Updated translations via Crowdin Fix the wrong push commits in the pull request when force push (go-gitea#36914)
Fix #36685
Generated by a coding agent with Codex 5.2 LLM.