ci: add PR validation check for type label or Conventional Commits title#423
ci: add PR validation check for type label or Conventional Commits title#423
Conversation
Add a CHANGELOG.md following the release-toolkit format with historical entries back to v0.3.0. Each version is categorized into Breaking Changes, New Features, Bug Fixes, and Internal Changes. The release script now automatically manages the Trunk section during releases, and the developer workflow docs mention updating the changelog when merging user-facing changes.
github-actions
bot
added
the
[Type] Developer Documentation
|
With #392, I attempted to automate change groups and avoid the need to manually type change log entries, including breaking changes. If a PR is labeled appropriately, its title is included in the GitHub Release notes in the corresponding group. If a PR title follows Conventional Commits spec, a GitHub Action automatically labels the PR appropriately. I.e., the PR title becomes the release note. Curious your thoughts: Is there value in a |
Address review feedback — the comprehensive per-PR lists are redundant with the auto-generated GitHub Release notes from #392. The CHANGELOG now focuses exclusively on breaking changes, which is the one thing GitHub Releases can't surface ahead of time via the Trunk staging area.
Ensures every PR has either a valid Conventional Commits prefix in the title (which triggers automatic labeling via label-pr.yml) or a manually applied [Type] label. This prevents PRs from falling through the cracks in auto-generated release notes.
The label-pr workflow already applies the [Type] Breaking Change label when it sees ! in the title — no need to warn about it separately.
The new PR validation check ensures every PR has either a Conventional Commits title or a type label, so GitHub Releases will reliably capture breaking changes going forward. A manual CHANGELOG is redundant.
jkmassel
force-pushed
the
jkmassel/add-changelog
branch
from
ad65bde to
75f39ed
Compare
jkmassel
changed the title
pull_request_target only runs the workflow from the default branch, so the check can't fire until it's merged — a chicken-and-egg problem. This workflow only needs read access (title + labels), so pull_request is the correct trigger. pull_request_target is only needed for the label-pr workflow which writes labels.
|
@oguzkocer – sorry about that. I fixed the issue and rebase your test PRs atop this one. They now pass/fail as expected. |
oguzkocer
left a comment
oguzkocer
left a comment
There was a problem hiding this comment.
This looks good to me. Claude brought up some considerations as shared below, but I don't think they are blocking. I'll leave it to you whether these are worth doing and it should be done in this PR.
Claude's review
-
Breaking change detection is captured but unused.
isBreakingis computed (line 29) but never referenced again. If it's intended for future use, I'd remove it now to avoid dead code — it can be re-added when needed. If it's supposed to do something (like warn or require a[Type] Breaking Changelabel), that logic is missing. -
styleprefix is included but has no corresponding[Type]label. If someone usesstyle:in their title, the check passes, but the auto-labeler (presumably) won't assign a type label. Is that intentional? Same question forchore:— is there a label mapping for it? -
typeLabelslist doesn't include all label categories. For example, there's no[Type] Code Styleor[Type] Chorein the array. If those labels exist, PRs with them wouldn't be recognized by this check. If they don't exist, then thestyleandchoreprefixes pass validation but can't be categorized by label alone.
jkmassel
force-pushed
the
jkmassel/add-changelog
branch
from
f2e2a03 to
f8e2aaa
Compare
Force-pushes (e.g. rebases) fire the synchronize event, not opened or edited. Without this, the check wouldn't re-run after a rebase.
jkmassel
force-pushed
the
jkmassel/add-changelog
branch
from
f8e2aaa to
aeb020d
Compare
|
The |
3 participants
Summary
validate-pr.yml) that fails if a PR has neither a valid Conventional Commits title prefix nor a[Type]labelThis closes the gap where PRs without a recognized prefix (e.g. "Move editor loading into the library") silently skip auto-labeling and fall through the cracks in release notes. With this check, every PR is guaranteed to be categorized — including breaking changes.
Test plan
feat: test) — check should pass[Type]label to the failing PR — check should re-run and pass