stop closing issues from the release workflow; GitHub already does it - #341
Merged
Conversation
Now that main is the default branch again, GitHub acts on "fixes #123" itself when the release merges those commits into main, seconds before this job runs. Closing them here was redundant. It also broke the v0.21.1 release. The job tried to comment on #123, which is a pull request, not an issue; commenting on a PR needs pull-requests: write, which this job deliberately does not have, so it failed with "Resource not accessible by integration (addComment)". #123 was in scope only because a commit message mentioned "fixes #123" as an example of the syntax rather than as a real reference -- the keyword regex cannot tell the difference. The job is renamed to annotate-issues and now does only what GitHub does not: records which release shipped the fix, and removes the "closed in dev" label that label-fixed-in-dev.yml applied while the fix was unreleased. Numbers that turn out to be pull requests, or not to exist, are skipped explicitly via the issues API's .pull_request field rather than by hoping a gh command fails. Adding the "closed in dev" label on pushes to dev is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Fixes the failure in the v0.21.1 release run, and removes work the release
workflow no longer needs to do.
Why the closing was redundant
With
mainas the default branch, GitHub acts onfixes #123itself when therelease merges those commits into
main— seconds before this job runs. Closingthem again here achieved nothing.
Why it actually broke
The job tried to comment on #123, which is a pull request. Commenting on a PR
requires
pull-requests: write, which this job deliberately does not have:#123 was in scope only because a commit message mentioned
"fixes #123"as anexample of the syntax, not as a real reference. The keyword regex cannot tell
the difference — a known limitation, which here escalated from harmless to a red
X on a release.
What the job does now
Renamed
close-issues→annotate-issues, doing only what GitHub does not:(skipped if already noted, so re-runs don't duplicate);
closed in devlabel applied bylabel-fixed-in-dev.yml.Numbers that are pull requests, or that don't exist, are now skipped
explicitly via the issues API's
.pull_requestfield, rather than by hoping aghcommand happens to fail — which is what went wrong, sincegh issue viewsucceeds on a PR number.
Adding the
closed in devlabel on pushes todevis unchanged.Validation
actionlint+shellcheckclean. The new skip logic was dry-run against thelive API for all three cases: #123 (a PR) → skipped; #317 (a real issue) →
proceeds; #999999 (nonexistent) → skipped.