ci: automate release notes and PR labeling#392
Merged
Conversation
Exclude Dependabot PRs from release notes and group changes into "Features & Enhancements", "Bug Fixes", and "Other Changes" categories using existing repository labels. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Apply repository type labels to PRs automatically when opened or edited, based on the Conventional Commits prefix in the PR title. Respects manually applied labels by skipping when a conflicting type label already exists. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add docs/code/developer-workflows.md covering Conventional Commits usage, PR guidelines, and automatic labeling rules. Add a Release Notes section to docs/releases.md explaining category groupings and Dependabot exclusions. Link both from docs/code/README.md. Replace the inline commit/PR guidelines in AGENTS.md with a pointer to the new doc. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
|
@dcalhoun This looks good, but I should mention that Claude found one potential issue (which most likely isn't a problem):
Also, can you clarify what is meant by, "Creating a release and confirming Dependabot PRs are excluded?" If this means a signed release build I don't believe I'm able to do that. |
Avoid including Dependabot alias.
- add Breaking Changes section to release.yml using [Type] Breaking Change label - update label-pr regex to correctly parse Conventional Commits breaking change indicator (!) - apply [Type] Breaking Change exclusively when ! is present, skipping the type label Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Excludes [Type] Automated Testing, [Type] Build Tooling, [Type] Task, [Type] Developer Documentation, and dependencies from the Other Changes category, keeping release notes focused on user-visible changes. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Member
Author
@nbradbury thanks for sharing. I was unable to find definitive documentation on which name is correct. I ultimately excluded both in bb3c820 to be sure. I add a few additional changes as well:
I meant creating a new release via the project's |
Contributor
|
@dcalhoun I'll approve this but wanted to mention a couple of items Claude suggested upon re-review:
|
4 tasks
jkmassel
added a commit
that referenced
this pull request
Apr 13, 2026
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.
jkmassel
added a commit
that referenced
this pull request
Apr 15, 2026
…tle (#423) * docs: add CHANGELOG.md with breaking change tracking 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. * docs: scope CHANGELOG.md to breaking changes only 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. * ci: add PR validation check for type label or Conventional Commits title 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. * ci: remove redundant breaking change warning from PR validation The label-pr workflow already applies the [Type] Breaking Change label when it sees ! in the title — no need to warn about it separately. * docs: remove CHANGELOG.md in favor of GitHub Releases 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. * ci: use pull_request trigger for PR validation 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. * ci: add synchronize trigger to PR validation workflow Force-pushes (e.g. rebases) fire the synchronize event, not opened or edited. Without this, the check wouldn't re-run after a rebase.
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.
What?
Adds GitHub configuration and documentation to automate release notes generation and PR labeling based on Conventional Commits.
Why?
Release notes were noisy — Dependabot dependency bump PRs dominated the changelog, making it hard to see meaningful changes. There was also no consistent labeling of PRs by type, and the commit/PR conventions lived only in AGENTS.md (AI agent guidance) rather than human-facing docs.
How?
.github/release.yml: Configures GitHub's automatic release notes to exclude Dependabot PRs and group changes into four categories — "Breaking Changes", "Features & Enhancements", "Bug Fixes", and "Other Changes" — using existing repository type labels. Noise labels ([Type] Automated Testing,[Type] Build Tooling,[Type] Task,[Type] Developer Documentation,dependencies) are excluded from "Other Changes" to keep the changelog focused on user-visible changes..github/workflows/label-pr.yml: On PR open or edit, parses the Conventional Commits prefix and breaking change indicator (!) from the PR title and applies the matching repository label. When!is present (e.g.feat!:,fix(scope)!:), only[Type] Breaking Changeis applied. Skips if a conflicting type label is already present, so developers can override the auto-assigned label.bin/release.sh: Release commits now follow the Conventional Commits format (chore(release): x.y.z).docs/code/developer-workflows.md(new): Human-facing documentation covering Conventional Commits usage, PR guidelines, and the automatic labeling rules.docs/releases.md: Added a "Release Notes" section explaining category groupings, Dependabot exclusions, and linking to the labeling rules.docs/code/README.md: Linked to the newdeveloper-workflows.md.AGENTS.md: Replaced inline commit/PR guidelines with a pointer to the new doc.Conventional Commits → label mapping:
feat[Type] Enhancementfix[Type] Bugperf[Type] Performancetest[Type] Automated Testingdocs[Type] Developer Documentationbuild,ci[Type] Build Toolingrefactor,task,chore,style[Type] Task![Type] Breaking ChangeTesting Instructions
We can forgo testing for now, as the changes will not take effect until they are merged.
Accessibility Testing Instructions
N/A — no UI changes.