Context
#253 adds a changelog to the GitHub Release body via generate_release_notes: true. It works, but the output is a flat list:
## What's Changed
* feat: enhance officer UX in application/consignment tables by @mushrafmim in #249
* refactor(database): switch sqlite driver to pure Go by @sthanikan2000 in #248
**Full Changelog**: .../compare/v0.3.0...v0.4.0
Grouping it into sections (Features / Fixes / Breaking changes / …) would make releases scannable, especially as the PR count per release grows.
The catch: .github/release.yml categorises by label, and this repo doesn't label PRs
GitHub's release-notes config supports labels and authors as category rules — not title patterns. And of the last 15 merged PRs, 13 carry no labels at all; only two have breaking change.
So adding .github/release.yml on its own would put nearly everything in the uncategorised catch-all — no better than today.
What this repo does have is strong title discipline: 29 of the last 30 merged PRs follow conventional commits (feat:, fix(scope):, refactor(x)!: …). That's the signal worth building on.
Two options
A — derive labels from the title (preferred). Add an autolabeler that maps the conventional-commit prefix to an existing label (feat: → Type/Feature, fix: → Type/Bug, refactor:/chore:/build:/ci: → Type/Improvement, docs: → Type/Docs, !/BREAKING CHANGE → breaking change), then add .github/release.yml grouping on those. Leverages the discipline that already exists and needs no change to how people work. The label set is already in place — nothing new to create.
B — adopt manual label discipline. Simpler to configure, but it asks every author to remember a label on every PR, and the 13/15 miss rate suggests that won't hold on its own.
Supporting change worth doing either way
Enforce the conventional PR title in CI. There is no title check today, and one of the last 30 already drifted ("Refactor HTTP utility functions and update handler implementations"). Option A depends on titles being reliable, so the check is a prerequisite rather than a nice-to-have. The sibling repo already does this with amannn/action-semantic-pull-request — worth copying for consistency.
Notes
- No dependabot exclusion is needed. This repo has no
.github/dependabot.yml and zero dependabot PRs to date, so the usual "filter out dependency bumps" motivation doesn't apply here. (Separately: the absence of dependabot is its own gap — nothing bumps the Alpine/Go/Node base tags or the floating action majors.)
.github/release.yml affects the API-generated notes, so it applies automatically to release.yml with no workflow change once the file exists.- Scope is presentation only — no change to what gets published or how the image is built.
Not urgent. Filed as a follow-up to #253 while the context was fresh.
Context
#253 adds a changelog to the GitHub Release body via
generate_release_notes: true. It works, but the output is a flat list:Grouping it into sections (Features / Fixes / Breaking changes / …) would make releases scannable, especially as the PR count per release grows.
The catch:
.github/release.ymlcategorises by label, and this repo doesn't label PRsGitHub's release-notes config supports
labelsandauthorsas category rules — not title patterns. And of the last 15 merged PRs, 13 carry no labels at all; only two havebreaking change.So adding
.github/release.ymlon its own would put nearly everything in the uncategorised catch-all — no better than today.What this repo does have is strong title discipline: 29 of the last 30 merged PRs follow conventional commits (
feat:,fix(scope):,refactor(x)!:…). That's the signal worth building on.Two options
A — derive labels from the title (preferred). Add an autolabeler that maps the conventional-commit prefix to an existing label (
feat:→Type/Feature,fix:→Type/Bug,refactor:/chore:/build:/ci:→Type/Improvement,docs:→Type/Docs,!/BREAKING CHANGE→breaking change), then add.github/release.ymlgrouping on those. Leverages the discipline that already exists and needs no change to how people work. The label set is already in place — nothing new to create.B — adopt manual label discipline. Simpler to configure, but it asks every author to remember a label on every PR, and the 13/15 miss rate suggests that won't hold on its own.
Supporting change worth doing either way
Enforce the conventional PR title in CI. There is no title check today, and one of the last 30 already drifted ("Refactor HTTP utility functions and update handler implementations"). Option A depends on titles being reliable, so the check is a prerequisite rather than a nice-to-have. The sibling repo already does this with
amannn/action-semantic-pull-request— worth copying for consistency.Notes
.github/dependabot.ymland zero dependabot PRs to date, so the usual "filter out dependency bumps" motivation doesn't apply here. (Separately: the absence of dependabot is its own gap — nothing bumps the Alpine/Go/Node base tags or the floating action majors.).github/release.ymlaffects the API-generated notes, so it applies automatically torelease.ymlwith no workflow change once the file exists.Not urgent. Filed as a follow-up to #253 while the context was fresh.