[ci]: Add path based PR labeling - #2281
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces automated, path-based labeling for the existing area/epp and area/dev labels using actions/labeler, and updates the area taxonomy documentation to reflect .github/labeler.yml as the canonical source for those two labels’ path globs (while keeping the remaining areas documented until their labels are created).
Changes:
- Add a new
pull_request_targetworkflow to apply area labels based on changed file paths. - Add
.github/labeler.ymldefining path globs forarea/eppandarea/dev. - Update
docs/area_taxonomy.mdto remove thearea/epp/area/devtable rows and document the new source-of-truth location.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| docs/area_taxonomy.md | Updates the taxonomy to point area/epp/area/dev to .github/labeler.yml and keeps the other (not-yet-created) area labels in the docs table. |
| .github/workflows/pr-area-labeler.yaml | Adds a PR workflow that runs actions/labeler to apply path-based area labels. |
| .github/labeler.yml | Defines the path globs for area/epp and area/dev used by the labeler workflow. |
elevran
left a comment
There was a problem hiding this comment.
do you want me to create all relevant labels and then amend the PR to reflect that?
Instead of doing it in two PR steps.
Let me know all missing labels (kind, area, etc) and I'll add them.
Or can merge as is.
WDYT?
If you can create the labels that would be great, thanks @elevran. Use the table doc in the PR as its the latest. Let me know when its done and I'll update this PR then. |
|
Setting PR to draft for now waiting on labels and updates required afterwards. |
|
@hickeyma all area labels created |
area/epp and area/dev currently exist as labels in the repo. The other areas are defined in docs/area_taxonomy.md for now. Wire up the two that exist via actions/labeler which also becomes the source of truth for their path globs instead of the docs table. The other eight stay in the table until their labels get created (llm-d#956). Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
6768789 to
b006332
Compare
All ten area/* labels now exist in the repo, so the remaining eight (scheduling, flowcontrol, kvcache, coordinator, sidecar, datalayer, telemetry, docs) can move from the docs/area_taxonomy.md table into .github/labeler.yml alongside area/epp and area/dev. labeler.yml is now the single source of truth for the path globs. The doc keeps only the /area directive and the additive-overlap rule. Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
The job only adds labels (sync-labels: false), unlike pr-kind-label.yaml remove then add sequence, so nothing a canceled run can leave in a bad state. Co-Pilot review: - llm-d#2281 (comment) Signed-off-by: Martin Hickey <martin.hickey@ie.ibm.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.
Suppressed comments (1)
docs/area_taxonomy.md:12
- The manual-labeling bullet has a broken inline-code path (leading space and missing
.github/prefix), and both bullets are missing trailing periods, which makes the docs harder to follow and the referenced path incorrect.
- Manually: add an `/area <name>` line to a PR or issue body (see ` github/workflows/pr-kind-label.yaml` and `.github/workflows/issue-kind-label.yaml`)
- Automatically: `.github/labeler.yml` applies the matching `area/*` label(s) on every PR

What type of PR is this?
/kind feature
What this PR does / why we need it:
All ten
area/*labels now exist in the repo. This wires up the remaining eight (area/scheduling,area/flowcontrol,area/kvcache,area/coordinator,area/sidecar,area/datalayer,area/telemetry,area/docs) viaactions/labeler, alongsidearea/eppandarea/dev..github/labeler.ymlis now the single source of truth for the path globs.docs/area_taxonomy.mddrops its table and keeps only the/areadirective explanation and the additive overlap rule./cc @elevran
Which issue(s) this PR fixes:
Partial #956 (Phase 4, Labeling)
Release note (write
NONEif no user-facing change):