Skip to content

ci: comment on issues auto-closed by a merged PR (merged != released)#151

Merged
theoephraim merged 2 commits into
mainfrom
feat/merge-issue-note
Jul 3, 2026
Merged

ci: comment on issues auto-closed by a merged PR (merged != released)#151
theoephraim merged 2 commits into
mainfrom
feat/merge-issue-note

Conversation

@theoephraim

Copy link
Copy Markdown
Member

Problem

When a PR with Closes #123 merges to main, GitHub closes the issue immediately — but with bumpy the fix is only merged, not published. To anyone watching the issue, "closed" reads as "shipped," which is misleading until the next release actually goes out.

Approach

Rather than fight GitHub's auto-close (deferring it isn't possible; reopening spams notifications), just leave a clarifying comment on each auto-closed issue:

✅ A fix has been merged to main in #142 and will ship in the next release.

GitHub auto-closed this issue on merge, but the change isn't published yet — it'll go out with the next bumpy release. 🐸

How it works

  • Triggers on pull_request_target: [closed], scoped to base branch main, gated on merged == true.
  • Uses the PR's GraphQL closingIssuesReferences to find exactly which issues were closed — resolves every Closes/Fixes/Resolves variant natively, no body regex.
  • One comment per closed issue.

Safety

  • pull_request_target gives the issues: write token, but the workflow never checks out or runs PR code — it only queries linked issues and posts a comment.
  • The workflow file always runs from main, so a fork PR can't alter it.
  • Only the PR number (int) and repo slug reach the shell — injection-safe.

Design notes

  • Kept separate from release.yaml on purpose. That workflow runs on the same merge (push: [main]), but a push event lacks the PR/closing-issue data, and its always-run plan job is deliberately zero-permission. This workflow is pure gh (no bun/build), so it's cheap to keep standalone.
  • Toggle is file presence — delete the workflow to disable. No config for v1.
  • Activates after merge to mainpull_request_target always uses the base-branch copy, so it won't run from this PR itself.
  • Scoped to main only — a next prerelease merge won't trigger it (the "next release" wording wouldn't fit).

Deferred

The release-time follow-up ("🎉 Released in vX.Y.Z") is intentionally left out — doing it reliably means distinguishing issue refs from PR refs in the release body, which is better solved by having bumpy track it than by regex. Happy to tackle in a follow-up.

GitHub closes an issue the instant a PR with `Closes #123` merges to main,
but with bumpy the fix is only merged, not published. "Closed" then reads as
"shipped" to anyone watching the issue. This adds a small workflow that leaves
a clarifying comment on each auto-closed issue: the fix is merged and will go
out in the next release.

- Triggers on pull_request_target: [closed] scoped to base branch main, gated
  on merged == true. Never checks out or runs PR code; only reads the PR's
  closingIssuesReferences (handles all Closes/Fixes/Resolves variants) and
  posts a comment. Injection-safe (only PR number + repo slug reach the shell).
- Kept separate from release.yaml on purpose: the push event there lacks the
  PR/closing-issue data, and release.yaml's always-run plan job is deliberately
  zero-permission. This is pure gh (no bun/build), so it's cheap to run standalone.
- Toggle is file presence; delete the workflow to disable.

Release-time follow-up ("Released in vX.Y.Z") intentionally deferred.
@theoephraim theoephraim merged commit 71d14b2 into main Jul 3, 2026
4 checks passed
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.

1 participant