Repository navigation
Conversation
Add a workflow that runs actions/labeler v7.0.0 when a PR is opened, reopened or marked ready for review. The rules in .github/labeler.yml add: - a `backend: *` label for each backend whose directory the PR touches (including its `experimental/` counterpart); - `category:internal` when every changed file is CI config, build-support, release tooling, `3rdparty/` or a Cargo manifest or lockfile; - `category:documentation` when every changed file is under `docs/docs/`. Labels are only added, never removed, and a PR that would gain more than three labels gains none, so tree-wide refactors are left alone. `release-notes:not-required` is never applied: that stays a human decision. The workflow uses `pull_request_target` so that PRs from forks get a token that can add labels. Nothing from the PR is checked out or run: the labeler lists changed files through the API and reads its config from the base branch. Disclosure: investigated and implemented with Claude.
Run the labeler on `synchronize` too. Each run looks at the PR's whole diff, so a later push that touches a new backend adds its label. The labeler keeps no state, so it also re-adds a matching label that someone removed by hand; that is acceptable for the `backend: *` labels, which nothing automated depends on. Drop the `category:internal` rule. The labeler never removes labels, so a PR that started out CI-only would keep the label after later pushes made it user-facing, and it would pass the release-notes check without anyone deciding that it needs no notes. Also write the trigger types as a block-style list.
sureshjoshi
added
the
release-notes:not-required
sureshjoshi
reviewed
Nov 14, 2026
| # `pull_request_target` rather than `pull_request`, so that PRs from forks get a token that can | ||
| # add labels. This is safe because nothing from the PR is checked out or run: the labeler lists | ||
| # the changed files through the API and reads .github/labeler.yml from the base branch. | ||
| pull_request_target: |
Member
There was a problem hiding this comment.
In spite of the comment, pull_request_target is unambiguously the largest source of CI security issues.
https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/
https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target#default-policy-for-pull_request_target
They're also quirky: https://github.com/actions/labeler#notes-regarding-pull_request_target-event
Do we really need it? What about a daily cron or something? I'm not too concerned about it on day 1, but more like, day 100 if someone mods it.
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
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.
Add a github workflow to automatically apply labels to prs based on the files that they changed. I tried to map existing labels to prefixes + set a limit on the maximum number of labels that would be applied on a per commit basis. I did not add release notes for this one as it isn't part of the package, so it wouldn't actually be included in a release.