You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cloudflare-worker: take back the labels that stopped being true
The bot applied "add package", "drop package" and release/<version>
whenever the condition held, and never took any of them off again. A
branch that dropped its new package during review, or was retargeted
from one release to another, kept a label saying otherwise - and the
nightly scan and everyone reading the list of pull requests believed
it. Only "stale" and the guidelines label were ever withdrawn.
All three are read straight off the pull request's own content, so the
bot now withdraws them on the same terms it applies them. Labels
matched from labeler.yml are deliberately left alone, the way GitHub's
own labeler action leaves them by default: a path label is as often put
on by hand as derived, and taking those back would fight whoever set
them.
A removal names the label the way the repository spells it rather than
the way the constant is written - openwrt/packages calls it "Add
package" - which the comparison, being case-insensitive, hid until now.
Deploying is also held back until the tests pass. deploy.yml and
tests.yml both triggered on a push to main, so they started in the same
second and raced: the Worker went live whether or not the suite ever
went green.
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: README.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -69,8 +69,8 @@ Scans the contribution tree for nested downstream patch targets:
69
69
### Automated Triage & Stale PR Management
70
70
71
71
***`not following guidelines`**: A high-visibility tag automatically attached to the PR if any critical validation check drops a failure blueprint. Clears itself upon a successful push.
72
-
***`add package` / `drop package`**: Dynamically analyzes unified diff targets to label tracking trees introducing or purging software packages.
73
-
***Stable Branch Tracking**: Auto-generates matching grey release tags (e.g., `release/24.10`, `release/25.12`) whenever a PR targets an active release backport branch.
72
+
***`add package` / `drop package`**: Dynamically analyzes unified diff targets to label tracking trees introducing or purging software packages. Both are withdrawn again once the branch stops adding or dropping a package, so a label never outlives what it describes.
73
+
***Stable Branch Tracking**: Auto-generates matching grey release tags (e.g., `release/24.10`, `release/25.12`) whenever a PR targets an active release backport branch, and removes a release tag that no longer matches after the pull request is retargeted. Labels matched from `labeler.yml` are only ever added, the way GitHub's own labeler action leaves them by default — a path label is as often set by hand as derived.
74
74
***Issue Labeller**: Replaces the GitHub Actions `issue-labeller.yml` workflow. When a bug-report issue is opened with the trigger label, the bot validates form fields and applies labels based on a declarative `.github/issue-labeller.yml` configuration file (same spirit as `labeler.yml` for PRs — label name → list of conditions). Supports template variables (`{major}`, `{segment0}`, etc.), format validation (regex), existence checks (tag/path via GraphQL), substring matching, and presence checks. Falls back to sensible defaults if no config file exists. Disabled by default — enable per-repository with `"enable_issue_labeller": true`.
75
75
* **Stale PR Cleanup**: A daily scheduled cron task (05:30 UTC) scans all repositories where the App is installed. If explicitly enabled in a repository's configuration (\`"enable_stale_bot": true\`), it marks PRs containing the \`not following guidelines\` label as \`stale\` (with a warning comment) after 14 days of inactivity, and closes them after another 14 days of silence. Only contributor activity resets the countdown: pushed commits, force-pushes, reopens, and comments or reviews from people. Comments from GitHub Apps, `*[bot]` accounts and the machine accounts listed in `stale_ignored_users` are ignored, so an automated review can never keep a dead PR alive forever. Pushing new commits also removes the `stale` label immediately via the webhook, without waiting for the nightly scan. The scan asks GitHub for each repository's configuration and its labelled pull requests in two GraphQL queries, timelines included, so its request count no longer grows with the number of stale pull requests. A pull request whose timeline is longer than the fetched window (the most recent 100 entries) is left untouched rather than judged on incomplete history.
commit: {message: 'mypkg: update to 1.2.3\n\nA description of the change.\n\nSigned-off-by: John Doe <john@doe.com>',author: {name: 'John Doe',email: 'john@doe.com'},committer: {name: 'John Doe',email: 'john@doe.com'}}
0 commit comments