Skip to content

ci: auto-merge release-please PRs on open - #166

Merged
mashkovd merged 1 commit into
mainfrom
feat/auto-merge-release-pr
May 23, 2026
Merged

mashkovd merged 1 commit into
mainfrom
feat/auto-merge-release-pr

Conversation

@mashkovd

Copy link
Copy Markdown
Member

Summary

Adds a workflow that automatically merges release-please PRs the moment they are opened (or updated).

  • Fires only on branches starting with release-please--; all other PRs are unaffected
  • Uses --admin to bypass the required-review gate (release PRs are always trivial: CHANGELOG + version bump)
  • Closes the last manual step in the deploy pipeline: commit → release-please → auto-merge → tag → release-deploy → ArgoCD → prod

Merge

Trivial CI config — merge immediately.

@mashkovd
mashkovd merged commit 844db5b into main May 23, 2026
7 checks passed
@mashkovd
mashkovd deleted the feat/auto-merge-release-pr branch May 23, 2026 15:11
@claude

claude Bot commented May 23, 2026 •

Copy link
Copy Markdown

Claude finished @mashkovd's task in 2m 6s —— View job


Review complete

  • Read workflow file
  • Analyze for correctness, security, and logic issues
  • Post findings and verdict

Verdict: Approved — no P1/P2 findings, 1 P3 nit.

The workflow is clean:

  • permissions: {} at the top level with job-scoped grants is correct least-privilege practice.
  • Branch-name guard (startsWith(github.head_ref, 'release-please--')) is the right filter; only repo members with write access can push such branches, so the security surface is equivalent to existing write access.
  • --admin bypass is intentional and correctly documented — needed to skip the required-review gate for trivially safe version-bump PRs.
  • GH_TOKEN: ${{ github.token }} (built-in, short-lived) is the right credential choice.
  • PR number and repo name passed as env vars rather than interpolated into the shell command — avoids injection.
  • Using pull_request (not pull_request_target) is the safer trigger choice; the job runs in the PR-head context, not the base-branch context.

P3 — synchronize may produce noisy failed runs in rare edge cases. If release-please rebases the PR after a new commit lands on main and the first merge has already completed, the synchronize re-trigger will call gh pr merge on an already-merged PR and exit non-zero. In practice this race is unlikely and harmless, but worth knowing.

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Trivial CI config — single workflow, correct branch-name guard, scoped job permissions, no long-lived secrets, env-var passthrough avoids shell injection. No P1/P2 findings (1 P3). Good to merge.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants