fix(ci): drop release-drafter PR trigger, finish v7 migration - #14
Merged
Conversation
release-drafter v7 split the action in two: the root action only drafts
releases, and the autolabeler moved to a separate sub-action. The workflow
still carried the v5/v6 layout, where one action did both and the pull_request
trigger existed solely for the autolabeler, per its own comment.
Under v7 that trigger autolabelled nothing and instead re-ran the drafter,
which tries to create the draft release. Harmless on same-repo PRs, but PRs
from forks get a read-only GITHUB_TOKEN regardless of the permissions block:
Creating new release...
Error: Resource not accessible by integration
Drop the pull_request trigger. The draft release is built from the commits on
main, so push is the only event it ever needed. Restoring autolabelling would
have required pull_request_target to get a writable token on fork PRs, which is
not worth it here: the labels feed only the changelog section headings and do
not affect version resolution at all, and the same information is already in
the conventional-commit title prefix that conventional-commits.yml enforces.
Categories stay in place for labels applied by hand, and sort-by: title now
groups entries by their conventional-commit prefix as a stand-in for the
section headings, descending so that fix and feat sort above docs and chore.
Also migrate .github/release-drafter.yml off the fields v7 deprecates, which
were emitting seven warnings per run: categories[*].labels moves into when,
exclude-labels becomes a pre-exclude category, and version-resolver becomes
version-resolver categories carrying semver-increment. Version resolution is
unchanged - nothing matching still falls back to patch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Kevin Stellmacher <dev@stellmacher.xyz>
trevex
approved these changes
Jul 29, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
release-drafter v7 split the action in two: the root action only drafts releases, and the autolabeler moved to a separate sub-action. The workflow still carried the v5/v6 layout, where one action did both and the pull_request trigger existed solely for the autolabeler, per its own comment.
Under v7 that trigger autolabelled nothing and instead re-ran the drafter, which tries to create the draft release. Harmless on same-repo PRs, but PRs from forks get a read-only GITHUB_TOKEN regardless of the permissions block:
Drop the pull_request trigger. The draft release is built from the commits on main, so push is the only event it ever needed. Restoring autolabelling would have required pull_request_target to get a writable token on fork PRs, which is not worth it here: the labels feed only the changelog section headings and do not affect version resolution at all, and the same information is already in the conventional-commit title prefix that conventional-commits.yml enforces. Categories stay in place for labels applied by hand, and sort-by: title now groups entries by their conventional-commit prefix as a stand-in for the section headings, descending so that fix and feat sort above docs and chore.
Also migrate .github/release-drafter.yml off the fields v7 deprecates, which were emitting seven warnings per run: categories[*].labels moves into when, exclude-labels becomes a pre-exclude category, and version-resolver becomes version-resolver categories carrying semver-increment. Version resolution is unchanged - nothing matching still falls back to patch.