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
Adds the pull request labeler as a reusable workflow + workflow template, following the same pattern as the target branch check — and combining the two so they run in the right order.
The combined workflow:
Label — the Label Classifier action (paulinevos/label-classifier@v1) suggests labels for a newly opened pull request by answering per-label policy questions against its context (title, description, commits, changed files, diff, base-revision documentation), applies the suggestion by adding labels only — existing labels are preserved — and posts one comment noting the labels were applied automatically from AI suggestions and should be checked by a human.
Check — the existing target branch check runs as a second job (needs: label), so an automatically applied label cannot miss its check. On reopened/labeled/unlabeled/edited events only the check runs — this template replaces the standalone check-target-branch template for repositories that adopt it; repositories that keep the standalone template are unaffected (refs are pinned per repository).
Requirements for consuming repositories:
the JEV_API_KEY secret, and optionally the JEV_ENDPOINT variable if the key is issued by a gateway other than Typesafe;
issues: write and pull-requests: write permissions (as in the template).
Safety:pull_request_target so fork pull requests are labeled too; the action never checks out or executes the pull request head — it only reads the event payload and runs its own pinned code.
Ref strategy: the template pins use_a_valid_ref_here per convention; the action is consumed by the floating v1 tag — flag it if Doctrine policy requires commit-SHA pinning instead.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
The workflow fails before suggesting labels because GITHUB_TOKEN is missing, and its undeclared JEV_API_KEY secret causes validation failures for callers using explicit secret mappings.
Although the classifier just missed the threshold for CI label at 0.78 😅. I'm inclined to keep it at 0.8 though cause in most cases it will apply correctly and I think under applying slightly is preferable to over applying (but lmk if you disagree)
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Automatic BC Break labels can escape target-branch validation because github.token label changes do not trigger the check, while contributor comments can suppress the promised human-review notice.
Restrict disclosure-comment suppression to the bot's exact notice marker
.github/workflows/label-pull-request.yml:43
The v1 action skips its disclosure comment whenever any existing PR comment contains label-classifier, regardless of author or whether it is an automatic-label notice. A contributor can therefore suppress the promised human-review notice simply by mentioning that string before the action reaches the comment step. Consume a revision that checks for an exact, bot-authored notice marker, or handle that check and comment in this workflow.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Shared concurrency can cancel initial automatic labeling, and manual runs omit the PR number from the branch check, allowing it to succeed without checking the targeted PR.
The reason will be displayed to describe this comment to others. Learn more.
Fixed: opening runs and check-only runs now use separate concurrency lanes (label-pull-request-N and check-target-branch-N, the latter matching the standalone check template). An edit during classification can no longer cancel it.
Consumes the Label Classifier action (paulinevos/label-classifier@v1), which
suggests labels for newly opened pull requests by answering per-label policy
questions against the pull request's context, applies the suggestion by
adding labels only, and comments that the labels were applied automatically
from AI suggestions and should be checked by a human.
The target branch check runs as a second job after labeling, so an
automatically applied label cannot miss its check. On reopened, labeled,
unlabeled, and edited events only the check runs, replacing the standalone
check-target-branch template for repositories that adopt this workflow.
Uses pull_request_target so pull requests from forks are labeled too; safe
because the action never checks out or executes the pull request head.
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
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.
Adds the pull request labeler as a reusable workflow + workflow template, following the same pattern as the target branch check — and combining the two so they run in the right order.
The combined workflow:
paulinevos/label-classifier@v1) suggests labels for a newly opened pull request by answering per-label policy questions against its context (title, description, commits, changed files, diff, base-revision documentation), applies the suggestion by adding labels only — existing labels are preserved — and posts one comment noting the labels were applied automatically from AI suggestions and should be checked by a human.needs: label), so an automatically applied label cannot miss its check. Onreopened/labeled/unlabeled/editedevents only the check runs — this template replaces the standalone check-target-branch template for repositories that adopt it; repositories that keep the standalone template are unaffected (refs are pinned per repository).Requirements for consuming repositories:
JEV_API_KEYsecret, and optionally theJEV_ENDPOINTvariable if the key is issued by a gateway other than Typesafe;issues: writeandpull-requests: writepermissions (as in the template).Safety:
pull_request_targetso fork pull requests are labeled too; the action never checks out or executes the pull request head — it only reads the event payload and runs its own pinned code.Ref strategy: the template pins
use_a_valid_ref_hereper convention; the action is consumed by the floatingv1tag — flag it if Doctrine policy requires commit-SHA pinning instead.