Automatically label documentation and maintenance PRs

[albertvillanova]

This PR adds a path based labeler, so the release notes sections stay populated without hand-labelling every pull request. Follow-up to #7166.

Motivation

The sections added in #7166 are driven by labels, but only 14 of the last 400 merged pull requests carried a label at all, and every one of those came from Dependabot. Hand-labelling decays. The part that can be read off the diff does not have to.

Solution

actions/labeler applies 📚 documentation and 🔧 maintenance from the changed paths. The labels that need judgement stay manual: a diff does not say whether a change under trl/ is a feature or a fix, so ✨ enhancement, 🐛 bug and 💥 breaking are deliberately absent here.

The rules use any-glob-to-all-files, so every changed file has to match and a pull request that also touches trl/ gets nothing. Replayed over the last 300 merged pull requests, this labels 49% of them (44% maintenance, 4% documentation), with no pull request touching trl/ or examples/ picking up a label. That asymmetry is the point: an unlabelled pull request falls through to Other, which is what the flat list already gives, while a wrong label is silently wrong.

This is not the labeller removed in #6052. actions/labeler is maintained by GitHub, never checks out the pull request, and needs no API token. It reads the config from the base branch, so a pull request cannot relabel itself, and it runs on the same pull_request_target surface as pr_template_check.yml today.

Changes

• Add .github/labeler.yml mapping paths to the two mechanical labels
• Add .github/workflows/labeler.yml running actions/labeler on pull_request_target, with sync-labels so a docs-only pull request that later grows a code change drops the label again

---

Note

Low Risk
CI-only GitHub Actions and label config; no application runtime or auth changes.

Overview
Adds automatic PR labeling so release-note sections get 📚 documentation and 🔧 maintenance without manual tagging, following the label-driven sections from #7166.

A new .github/labeler.yml maps paths with any-glob-to-all-files: every changed file must match, so mixed PRs (e.g. docs/ plus trl/) get no auto label and still land in “Other”. Judgement labels (✨ enhancement, 🐛 bug, 💥 breaking) are intentionally omitted.

A Labeler workflow runs pinned actions/labeler v7 on pull_request_target (opened/synchronize/reopened) with pull-requests: write, matching the fork-friendly pattern used by pr_template_check.yml. Config is read from the base branch; sync-labels is not enabled so hand-applied labels are not stripped and docstring-only edits stay unlabeled.

^{Reviewed by Cursor Bugbot for commit cccaf47. Bugbot is set up for automated code reviews on this repo. Configure here.}

[bot-ci-comment]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 72d22c8. Configure here.}

[qgallouedec]

IIUC One side effect of sync-labels worth knowing: for the two labels in the config it overrides manual ones as well. So those two become effectively read-only. The other three aren't in the config so they're untouched. Fine by me, just noting it.

LGTM

I guess we'll have to see how it behaves and refine if necessary

[albertvillanova]

You are right, @qgallouedec.

I am removing sync-labels: adding is unconditional, so dropping sync-labels keeps the useful half: it still runs on synchronize and still adds a label when a pull request grows into a category, it just stops removing.

What that buys is that both labels stay writable by hand, and 📚 documentation needs that more than it looks. A lot of our documentation work is docstrings, and docstrings live in trl/, so path matching will never derive the label for it. A pull request that reformats docstrings to the repo style, or one that updates a guide in docs/ together with the docstrings it mirrors, is documentation and nothing else, yet by path it touches code. Labelling it by hand is the only way it lands in the right section. The same holds for the upkeep pull requests under trl/ that match no glob, where 🔧 maintenance is right and nothing derives it. With sync on, either label only sticks if nobody pushes again.

The trade is that a docs-only pull request which later grows a code change keeps 📚 documentation. I don't think this is a common case.