feat(release): auto-approve release PRs via dedicated GitHub App - #192
Merged
Conversation
…ease
The auto-merge reconcile step in the release workflow reads the current
version from .release-please-manifest.json on the base branch. On a fresh
repo the manifest is "{}" until the first release lands, so jq returns
"null" for the "." key. The subsequent numeric -gt comparisons then all
fall through and classify the bump as "none", which is never auto-merged
at any auto-merge-level.
Normalize a missing "." key to "0.0.0" so the first release is bump-classified
correctly (e.g. 0.0.0 -> 1.0.0 = major, 0.0.0 -> 0.1.0 = minor). Whether the
PR actually auto-merges still depends on the configured auto-merge-level.
Branch protection's required-approval rule blocks `gh pr merge --auto` from ever completing the merge on release-please PRs: the PR author is the release-please App (which cannot self-approve), no human is meaningfully reviewing the auto-generated CHANGELOG diff, and bypass_pull_request_allowances on classic branch protection only allows direct branch pushes — not merging un-approved PRs via the API (empirically verified). Add an optional auto-approve step that uses a dedicated `release-please-approver` App to submit an approving review. The App is intentionally distinct from the release-please App that authors the PR so the review counts. With approval in place, the existing `--auto --squash` step merges as soon as required checks pass. Optional by design: if the approver secrets are not provided, both new steps are skipped and existing callers see no behavior change.
5 tasks
The body added noise to the PR review history without giving reviewers useful information. The rationale lives in the YAML comment above the step, which is the right place for it.
fiunchinho
marked this pull request as ready for review
June 1, 2026 12:11
The previous description was 248 chars; project's yamllint config caps lines at 200. Trim wording without losing the key signal (optional + what gets skipped when omitted).
QuentinBisson
approved these changes
Jun 1, 2026
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
gh pr merge --autonever completes on release-please PRs in repos with required-approval branch protection, because nothing satisfies the approval requirement:release-please-workflowApp, which cannot self-approve.bypass_pull_request_allowanceson classic branch protection does not allow merging un-approved PRs via the API — empirically verified by attemptinggh pr merge --squashauthenticated as the bypass App and gettingthe base branch policy prohibits the merge. The bypass only covers direct branch pushes.This PR adds an optional auto-approve step that uses a dedicated
release-please-approverGitHub App to submit an approving review. The App is intentionally distinct from the release-please App that authors the PR (so the review counts). With approval in place, the existing--auto --squashstep merges as soon as required checks pass.Scope
steps.release_please.outputs.pr— there is no path for this step to touch non-release-please PRs.RELEASE_PLEASE_APPROVER_CLIENT_ID/RELEASE_PLEASE_APPROVER_PRIVATE_KEYarerequired: false. Callers that don't provide them see no behavior change.Caller-side requirements
Repos that want to opt in need to:
release-please-approverApp.RELEASE_PLEASE_CLIENT_ID/RELEASE_PLEASE_PRIVATE_KEY).secrets:block of their generatedrelease-please.yamlworkflow file. devctl template update required for org-wide rollout — out of scope for this PR.App permissions — important
The approver App needs
Contents: Read and writein addition toPull requests: Read and write. `Contents: Read` alone is not enough — GitHub will silently submit the review but not count it toward branch protection's required-approval rule (`authorAssociation` reports `NONE` and `reviewDecision` stays `REVIEW_REQUIRED`). This is poorly documented; the symptom is "the approval is recorded but the PR still says review required." Empirically verified end-to-end on `giantswarm/test-release-please`.Verified end-to-end
Tested on `giantswarm/test-release-please` against the live branch protection (1 required approval). With the approver App's review counting, `gh pr merge --auto --squash` completed the merge and cut `v1.0.0` ~30 seconds after the workflow run started.
Test plan