Task/awaiting response label - #2647
Open
alleria173 wants to merge 5 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.
Contributor
Author
|
Hi there. Let me know if you need any more commentary/tests to support this pull request. |
Comment on lines
+55
to
+64
| // Case 1: merge conflict -> the author needs to resolve it. | ||
| // mergeable_state can be temporarily "unknown" while GitHub computes | ||
| // it; those PRs are picked up on a later run instead of retrying now. | ||
| if (pr.mergeable_state === 'dirty') { | ||
| await github.rest.issues.addLabels({ | ||
| owner, repo, issue_number: pr.number, labels: [awaitingLabel], | ||
| }); | ||
| core.info(`#${pr.number}: added "${awaitingLabel}" (merge conflict).`); | ||
| continue; | ||
| } |
Contributor
There was a problem hiding this comment.
I think this case can be removed. In many/most cases the merge conflict is for a reason well known to the maintainers and we will normally clean these up as part of the PR merge process.
If it's not for an obvious/known reason (or the PR author has built their branch from a significantly stale fork of the repo) then we'll add a review comment asking them to resolve the merge conflict, which is then caught by the following case.
Contributor
Author
There was a problem hiding this comment.
Thanks for the input - that makes sense. I've removed that case as you suggested.
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.
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 labels a PR when the most recent review requested changes and the author hasn't pushed or commented since. (An earlier revision also labelled PRs with a merge conflict; that case was removed following review feedback, since maintainers usually know the reason and handle it directly as part of the merge process, or leave a review comment asking the author to resolve it — which is then caught by the changes-requested case above.)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.