Task/awaiting response label#2647
Open
alleria173 wants to merge 3 commits into
Open
Conversation
…nse' label for cases where reviewer asks a question
Review events on fork PRs run with a read-only token, so labels can't be added from the pull_request_review trigger. Move label-adding to a daily scheduled scan, which also covers PRs with merge conflicts. The event-driven workflow now handles removal only.
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.
Description
Adds two workflows that manage an "awaiting response" label on pull requests, to make it easy to see which PRs are waiting on their author versus waiting on a maintainer:
awaiting-response-label.yml(event-driven) — removes the label as soon as the author responds, either by pushing a new commit or by leaving a comment on the PR. Follows the same pattern as the existing "awaiting cla" labelling workflow (Add a workflow to automatically flag PRs without a signed CLA #2627).awaiting-response-scan.yml(scheduled, daily) — adds the label to open PRs that are waiting on their author, following the scheduled-workflow precedent set by Feature: automatically expire PRs if CLA remains unsigned for an extended period #2636. It covers two cases: the PR has a merge conflict, or the most recent review requested changes and the author hasn't pushed or commented since.A scheduled scan is used for adding the label (rather than reacting to review events directly) because GitHub gives workflows a read-only token when they are triggered by reviews on PRs from forks — which is how most contributions arrive — so an event-driven approach cannot apply labels in exactly the cases that matter. Label removal is not affected because the events it uses (
pull_request_target,issue_comment) always run with a write-capable token. This behaviour was confirmed by testing against a fork.Maintainers can also add the label manually at any time (e.g. after asking a question in a comment) — the automatic removal treats manually-added labels identically.
The scan only examines up to 200 most-recently-updated open PRs per run and makes ~2-3 API requests per unlabelled PR, keeping a full sweep of the current backlog (~124 open PRs) comfortably within the GITHUB_TOKEN rate budget.
Possible follow-up, not included here: automatically closing PRs that keep the label for an extended period, following the approach of #2636 (
actions/stalescoped withonly-labels: 'awaiting response'). Left out deliberately as the issue notes this needs more consideration.Existing Issue
Fixes #2637
Screenshots
N/A — this change only adds GitHub Actions workflow files, it doesn't affect the CyberChef UI.
AI disclosure
Used Claude Code (Anthropic) to help design and write these workflows. I have reviewed the logic myself and understand how it works.
Test Coverage
No automated tests apply since these are GitHub Actions workflows rather than application code. The event-driven removal workflow was verified end-to-end on a fork with a test PR from a second account: the label was correctly removed both when the author pushed a follow-up commit and when the author left a comment. The same testing confirmed that review-triggered labelling cannot work for fork PRs (read-only token), which motivated the scheduled scan. The scan workflow supports
workflow_dispatchso it can be run manually and its per-PR decisions inspected in the run logs before the schedule takes over.