Skip to content

Require a release-notes label on every pull request - #42

Merged
dirkwa merged 3 commits into
mainfrom
ci-require-pr-label
Aug 8, 2026
Merged

dirkwa merged 3 commits into
mainfrom
ci-require-pr-label

Conversation

@dirkwa

@dirkwa dirkwa commented Aug 8, 2026

Copy link
Copy Markdown
Collaborator

#41 made the release notes group by label. This makes sure the labels are actually there.

Without it the failure is silent: an unlabelled PR still appears in the notes, just dumped in "Other". That is what every PR merged before #41 did — I had to go back and label #34 and #36#40 by hand so the 3.0.0 notes would read properly. This check moves that discovery to while the PR is open, when labelling costs nothing.

Accepted labels

feature, enhancement, fix, bug, documentation, dependencies, skip-changelog

Exactly one is required.

These are deliberately not signalk-server's list (fix, feature, doc, chore, test, ignore, other, dependencies, refactor). Four of those — chore, test, refactor, other — have no category in this repo's release.yml, so a PR could pass the gate and still land in "Other", which is the exact failure the gate exists to prevent. And doc/ignore would duplicate the documentation/skip-changelog already in use here.

So the gate accepts precisely what release.yml categorises. Verified as an invariant rather than by eye:

gate accepts     : bug, dependencies, documentation, enhancement, feature, fix, skip-changelog
release.yml knows: bug, dependencies, documentation, enhancement, feature, fix, skip-changelog

accepted but uncategorised: none
categorised but unreachable: none

AGENTS.md notes the two files as a pair, since adding a label to one without the other reopens the hole.

Dependabot is skipped

It applies dependencies itself, but not before this first runs on opened — the check would fail, then pass on the relabel, producing a red tick on every dependency PR for no reason. release.yml categorises those by author regardless.

Tested

The invariant above was checked by parsing both files and diffing the label sets. {{ errorString }} in the failure message is confirmed against the action's documented template variables. YAML parses; typecheck, lint, format, 79 tests and build all pass.

This PR is itself the first to go through the gate.

release.yml groups the generated notes by label, so an unlabelled PR lands
silently in "Other" — which is what every PR merged before it existed did.
Fail the check while the PR is still open and labelling costs nothing,
rather than discovering it at tag time.

The accepted labels are exactly the ones release.yml categorises, so a PR
that passes cannot end up uncategorised. Both files are listed in AGENTS.md
as a pair to keep them in step.

Dependabot is skipped: it applies `dependencies` itself, but not before this
first runs on `opened`, so the check would fail and then pass on the
relabel. Those PRs are categorised by author in release.yml anyway.
@dirkwa dirkwa added the enhancement New feature or request label Aug 8, 2026
{{ errorString }} is only the quantifier the action substitutes into
"requires {{ errorString }} {{ count }} of" — one of exactly, at least,
at most. Used on its own it rendered as "and has exactly.", which says
nothing about what is wrong.

{{ applied }} lists the labels the PR actually has, which is the part
someone reading a failed check needs.
@dirkwa dirkwa removed the enhancement New feature or request label Aug 8, 2026
{{ applied }} is empty in the common case — a PR with no labels at all —
so the message ended "and has: .". The tokens the action offers describe
the rule, not what the reader should do about it; the list to choose from
is fixed, so state it plainly.
@dirkwa dirkwa added the enhancement New feature or request label Aug 8, 2026
@dirkwa
dirkwa merged commit 54d310a into main Aug 8, 2026
25 of 26 checks passed
@dirkwa
dirkwa deleted the ci-require-pr-label branch August 8, 2026 20:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant