ci: auto-label pull requests by component and area - #2240
Conversation
Adds a path-based labeler so every pull request arrives routed to the package it changes and the analyzer subsystem it touches, instead of being triaged by hand. Uses pull_request_target for the same reason label-external.yml does: fork pull requests get a read-only token on pull_request, so the label call would fail silently. The action never checks out or runs pull request code, and both the workflow and the config are read from the base branch, so a pull request cannot alter its own label rules. sync-labels is left off so hand-applied triage labels are never removed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0183ij1wiTEcd8wA58xY7e6C
Coverage report (presidio-anonymizer)Click to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Coverage report (presidio-structured)Click to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||
Coverage report (presidio-cli)Click to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||
There was a problem hiding this comment.
🟢 Approval recommended
The change is limited to GitHub automation configuration and appears consistent with existing repo workflow patterns (including pull_request_target usage and action pinning).
Pull request overview
Adds automated path-based labeling for pull requests, improving triage by applying component/area/type labels based on which parts of the repository a PR changes.
Changes:
- Add a
pull_request_targetworkflow to apply labels usingactions/labeleron PR open/sync/reopen events. - Define label-to-path mapping rules for components, analyzer subsystems (areas), and change types (test/ci/dependencies).
File summaries
| File | Description |
|---|---|
.github/workflows/label-areas.yml |
New workflow which runs actions/labeler to apply labels on relevant PR events. |
.github/labeler.yml |
New labeler configuration mapping changed paths to component/area/type labels. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Coverage report (presidio-image-redactor)Click to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||||||||||||||
Coverage report (presidio-analyzer)Click to see where and how coverage changed
The report is truncated to 25 files out of 81. To see the full report, please visit the workflow summary page. This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Samples are documentation but also code that has to keep working, so they need to be findable on their own rather than only under documentation. Reuses the existing `samples` label. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0183ij1wiTEcd8wA58xY7e6C
The header described two facets while the file defines three, and `samples` sat under the component heading rather than type. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0183ij1wiTEcd8wA58xY7e6C
There was a problem hiding this comment.
🟢 Approval recommended
Only minor documentation/comment clarity issues were found; the workflow and label rules appear correct and consistent with existing repo patterns.
Review details
Suppressed comments (2)
Previously missed (2) — in code that hasn't changed since the last review.
.github/labeler.yml:6
- The header comment says only "Two facets" (component/area), but this file also defines a third facet (type) below. Updating the comment will prevent confusion for future maintainers.
.github/labeler.yml:13 - This note implies sync-labels will remove hand-applied triage labels, but this workflow currently sets sync-labels: false. Consider wording this as a conditional to avoid suggesting labels will be removed in the current setup.
- Files reviewed: 2/2 changed files
- Comments generated: 0 new
- Review effort level: Lite
There was a problem hiding this comment.
🟡 Changes recommended
The new label rules include at least one path glob that will mislabel unrelated changes (e.g., the deployment label matching the /presidio meta-package directory), reducing labeling accuracy.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
Suppressed comments (2)
Previously missed (2) — in code that hasn't changed since the last review.
.github/labeler.yml:66
deploymentcurrently matchespresidio/**, but/presidiois a Python meta-package (not deployment configuration). This will mislabel meta-package PRs asdeployment; consider removing this glob (Dockerfiles and compose files are already covered by the other patterns).
.github/workflows/label-areas.yml:1- The workflow name says it labels PRs "by area", but this workflow applies all labels from
.github/labeler.yml(component + area + type). Renaming the workflow makes the Actions UI clearer and avoids confusion for maintainers.
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
The workflow and step names described component and area only, while the config also applies type labels. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0183ij1wiTEcd8wA58xY7e6C
There was a problem hiding this comment.
🔵 Needs a closer look
The labeler config misses some intended documentation paths (e.g., structured docs and nested markdown), so certain PRs won’t be labeled as expected.
Review details
Suppressed comments (2)
Previously missed (2) — in code that hasn't changed since the last review.
.github/labeler.yml:47
structured-datacomponent label only matchespresidio-structured/**, but there are structured-data docs underdocs/structured/**and structured-specific markdown underdocs/**/*structured*.md(e.g.,docs/structured/index.md,docs/api/structured_python.md). As-is, PRs that only update structured docs won’t get thestructured-datalabel.
.github/labeler.yml:74- The
documentationlabel currently includes*.md, which only matches markdown files in the repo root and won’t match nested docs likepresidio-analyzer/README.mdor.github/PULL_REQUEST_TEMPLATE.md. If the intent is to label documentation changes across the repo, this glob should be recursive.
- Files reviewed: 2/2 changed files
- Comments generated: 0 new
- Review effort level: Lite
RonShakutai
left a comment
There was a problem hiding this comment.
LGTM left 1 tiny comment.
Change Description
Adds
actions/labelerso every pull request is labelled from its changed paths, instead of being triaged by hand.Two new files:
.github/labeler.yml— path rules across three facets: component (which package), area (which analyzer subsystem), and type (samples,test,ci,dependencies)..github/workflows/label-areas.yml— runs the labeler onopened,synchronizeandreopened.No behavior change to any Presidio package. This only affects repository automation.
Why this is worth doing
The immediate goal is a project board of open pull requests grouped by topic, so triage starts from "what is in each area" rather than a flat list of 50-plus pull requests. A board needs a reliable grouping key, and today there is none: the areas that actually generate the most work — YAML configuration and registry loading, context enhancement, NLP backends — have no label to group or filter on.
This change supplies that key. Once the labels are populated, the board can be built on top in either form:
is:open is:pr label:yaml-config), which needs no further setup.Topicsingle-select field mirroring the area labels, auto-populated by the built-inis:pr is:openadd workflow.Labelling every pull request by hand would not sustain either one, which is why this is automated rather than a one-off pass.
Why
pull_request_targetSame reason
label-external.ymlalready uses it: on apull_requestevent from a fork, GitHub issues a read-only token and the label call fails silently. The usualpull_request_targetrisk does not apply here, because the action never checks out or executes pull request code — it reads the changed-file list through the API — and both the workflow andlabeler.ymlare read from the base branch, so a pull request cannot change the rules that label it.sync-labelsis left atfalse, so labels applied by hand are never stripped.Labels
All 17 label names the config references now exist in the repository, so the labeler reuses them and creates nothing implicitly. Ten were already in use (
analyzer,anonymizer,image-anonymization,dicom,structured-data,documentation,samples,deployment,dependencies,PII recognizers). Seven were added for this change:context-enhancementcontext_aware_enhancers/**yaml-configinput_validation/**,recognizer_registry/**,conf/**nlp-enginenlp_engine/**,chunkers/**,llm_utils/**rest-apipresidio-*/app.py,docs/api-docs/**clipresidio-cli/**test**/tests/**,e2e-tests/**ci.github/workflows/**,.github/pipelines/**context-enhancementandyaml-configare named to match the review rulebooks in.github/instructions/, so the label tells a reviewer which instruction file applies to the change.Notes for review
docs/samples/**gets bothsamplesanddocumentationfor the same reason — a sample is documentation, but it is also code that has to keep working.analyzerwill match nearly every analyzer pull request, including recognizer and YAML-config ones. That is intended — filtering happens on the area labels.PII recognizers,Performance,Advanced) are deliberately left out of this change, since renames happen in repository settings rather than in a diff.actions/labeleris pinned to the commit SHA for v6.2.0, matching the convention inlabel-external.ymland the request in Pin GitHub Actions to full-length commit SHAs #2230.Issue reference
No existing issue. Proposed while reviewing the open pull request and issue backlog, as the prerequisite for a topic-based board of open pull requests.
Checklist
labeler.yml.🤖 Generated with Claude Code
https://claude.ai/code/session_0183ij1wiTEcd8wA58xY7e6C