ci: add needs-attention labeling automation - #2432
Merged
Merged
Conversation
Mirrors the workflow added to react-native-firebase, firebaseui-web, and FirebaseUI-iOS. Two behaviors: - New issues/PRs (including from forks, via pull_request_target) get "needs-attention" immediately on creation. - When the issue/PR author comments on an open item, "needs-attention" is (re-)added and "blocked: await customer response" is removed. Closed items get a short comment instead, pointing to a fresh issue/PR if still relevant. Uses only the default GITHUB_TOKEN with an explicit permissions block, so no repository/org settings changes are required.
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
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
github-project-automation
Bot
moved this from Backlog
to Done
in studio-2394994192-60a69
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 the same automation added to react-native-firebase, firebaseui-web#1426, and FirebaseUI-iOS#1380: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-attentionandblocked: await customer responselabels, so no manual label setup is needed.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
master, then open a new issue and confirm it's immediately labeledneeds-attention.