ci: add needs-attention labeling when OP responds - #1380
Merged
Conversation
Mirrors react-native-firebase's issue-labels workflow: when the issue or PR author comments on an open item, add the "needs attention" label and clear "blocked: await customer response". Closed items get a short comment pointing the author to open a fresh issue/PR instead.
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
Adds issues:opened and pull_request_target:opened triggers so new items get "needs attention" immediately, without waiting for an OP comment. pull_request_target (rather than pull_request) is used so labeling still works for PRs from forks, since it runs with the base repo's token/permissions instead of being downgraded to read-only.
3 tasks
zizmor (mandatory security scan on this repo) flagged pull_request_target
as a fundamentally insecure trigger, and both permissions entries as
overly broad at the workflow level.
- Drop the pull_request_target trigger and its "label new PRs on open"
job entirely, since it can't be made safe enough for this org's
security gate. New issues are still labeled immediately (issues:opened
doesn't carry the same risk); new PRs are still labeled as soon as the
OP comments, via the existing issue_comment flow.
- Move permissions to job level (issues: write only) instead of the
workflow level, and set permissions: {} at the top. pull-requests: write
was dropped entirely - every API call here (addLabels/removeLabel/
createComment) goes through the Issues API regardless of whether the
target is an issue or PR, so it was never actually needed.
v9.0.0 is an annotated tag; the SHA copied from react-native-firebase's workflow (d746ffe3...) is the tag *object*'s SHA, not the commit it points to, so it 422s on a plain commit lookup. zizmor's impostor-commit check flags this as a version-comment mismatch. Repin to the underlying commit (3a2844b7...), which still corresponds exactly to v9.0.0.
demolaf
approved these changes
Jul 30, 2026
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
issue_comment+issues:openedworkflow, mirroring react-native-firebase's issue-labels automation, with one extra behavior on top:needs attentionlabel.needs attentionand removesblocked: await customer response(if present).GITHUB_TOKEN, withpermissions: {}at the workflow level andissues: writescoped per-job (nopull-requests: write— every call here goes through the Issues API regardless of whether the target is an issue or PR). No repository/org settings changes required.actions/github-scriptis pinned to the underlying commit SHA forv9.0.0rather than the annotated tag object's SHA (which 422s on a plain commit lookup and trips zizmor's impostor-commit check).Notes
needs attentionlabel does not exist in this repo yet; please create it before/after merging (lowercase, per repo convention) so the workflow can apply it.blocked: await customer responsealready exists and is reused as-is.pull_request_target, but this repo's mandatoryzizmorsecurity scan flagspull_request_targetas a fundamentally insecure trigger — it can't be made safe enough for that gate, so it was dropped. New PRs still get labeled as soon as the OP comments, via the existingissue_commentflow.Test plan
main, then open a new issue and confirm it's immediately labeledneeds attention.