semantic-release: bang-style breaking commits (`feat!:`) produce no release at all

[devantler]

🤖 Generated by the Daily AI Engineer

Evidence

While wiring create-release.yaml into devantler-tech/world-at-ruin, I measured what the
portfolio's standard .releaserc actually does with a bang-style breaking commit. Tested with
semantic-release@25.0.3 (the exact version create-release.yaml pins) against a clean baseline —
a local tag at HEAD, so only the test commit is analysed:

commit	bare .releaserc	expected
feat!: …	no release at all	major
fix!: …	no release at all	major
feat(scope)!: …	no release at all	major
feat: …	minor	minor
fix: …	patch	patch
docs: / chore: / ci:	no release	no release
feat: + BREAKING CHANGE: footer	major	major

The failure mode is not a wrong bump — a bang-style breaking change produces no release
whatsoever, so it ships silently unversioned and consumers never learn the API broke.

Cause: @semantic-release/commit-analyzer defaults to the Angular preset, which recognises
only the BREAKING CHANGE: footer, not the Conventional Commits ! shorthand.

Why this is portfolio-wide, not a world-at-ruin quirk

Every .releaserc in the org is the bare form (ksail, go-template, dotnet-template,
platform, platform-template, gitops-tenant-template, aws, .github, wedding-app,
ascoachingogvaner, and actions' own test fixture) — some with extra releaseRules, none
configuring the bang.

Meanwhile the org commit-message ruleset explicitly permits it:

^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?:
                                                                                ^^^^^

So the org's own rules invite feat!:, and the release pipeline then silently drops it. Any repo
here is one bang-commit away from an unreleased breaking change.

Hypothesis

Fixing this centrally in create-release.yaml removes the trap for every consumer at once, rather
than requiring each repo to discover it independently.

Proposed direction

Two options, and I'd like a steer:

1. Install the preset in the shared workflow — add
   conventional-changelog-conventionalcommits to the npx invocation so consumers can set
   "preset": "conventionalcommits", which handles ! natively. Verified it is not currently
   available: with the bare npx semantic-release@25.0.3, that preset fails with
   Cannot find module 'conventional-changelog-conventionalcommits'. Cleanest semantically, but
   changes the shared workflow's dependency surface for everyone.
2. Document the per-repo .releaserc fix — parserOpts.breakingHeaderPattern plus a
   breaking: true release rule, which works with only bundled dependencies. This is what
   world-at-ruin now ships (ci: split CI from CD and adopt semantic-release via .releaserc world-at-ruin#108); verified across all eight commit
   forms above, with the BREAKING CHANGE: footer path unaffected.

Option 1 is the better fix if the added dependency is acceptable; option 2 is already proven and
needs no change here.

Acceptance criteria

• feat!: / fix!: / feat(scope)!: produce a major release on a repo using the shared
  workflow.
• feat:, fix:, docs:, chore:, ci: and the BREAKING CHANGE: footer path are
  unchanged (verified, not assumed — this is the regression risk).
• Existing consumers are migrated or explicitly confirmed unaffected.

Size

Small-to-medium — the change is tiny; the care is in not regressing bump behaviour across ~10 repos.

[coderabbitai]

🔗 Related PRs

#412 - ci: skip the suite on the release-commit push to dodge the self-pin tag race [merged]
#427 - fix: resolve first-party self-references at the same commit [merged]
#467 - docs: standardize opt-in default-off flag convention for shared CI [merged]
#575 - fix(auto-merge): harden mutable review evidence [merged]
#612 - fix(release): disable issue notification hooks [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[devantler]

🤖 Generated by the Daily AI Engineer

Maintainer direction: fix this centrally. Implemented in #655.

Investigated which "central" is actually achievable, since semantic-release's config model constrains
it. Findings, all measured:

extends merge semantics decide the design. Tested three shapes:

consumer .releaserc	feat!:
{extends: shared, branches} — no local plugins	major ✅
bare config (today)	no release ❌
extends plus a local plugins array	no release ❌

A local plugins array replaces the shared one rather than merging. So a shared config works,
but only for consumers that drop their own plugins key — which means a fully zero-touch central
fix is not possible through extends. What is possible, and what #655 does, is better than
per-repo patching: plugin policy moves into one place, so this fix and every future one is
central, and each consumer's .releaserc shrinks to two lines.

Option 1 from this issue (install the conventionalcommits preset) is not viable. Verified it
is not bundled — Cannot find module 'conventional-changelog-conventionalcommits' — so it would add
a dependency to the shared workflow for every consumer. parserOpts.breakingHeaderPattern plus a
breaking: true rule achieves the same with bundled dependencies only.

Delivery. The config is written inline by create-release.yaml into
node_modules/@devantler-tech/release-config. A reusable workflow has the consumer's repo checked
out, so it cannot read its own release-config/ without a second checkout at a ref it cannot
reliably derive; inlining pins the config to the same commit consumers already pin by SHA.
release-config/ keeps reviewable copies and a self-test fails on drift.

Guard added. .github/tests/test-release-config-bumps.sh asserts the real bump matrix by running
semantic-release against fixture commits — RED/GREEN proven on both drift and behaviour. A
config-shape assertion would not have caught the original bug, which is why the existing
test-create-release-config.sh did not.

Remaining: consumer migration

#655 is additive, so nothing changes until a repo opts in. Migration is a two-line .releaserc per
repo (extends + branches, dropping plugins), across ksail, platform, go-template,
dotnet-template, platform-template, gitops-tenant-template, aws, .github, wedding-app and
ascoachingogvaner. Holding that sweep until #655 is reviewed rather than opening eleven PRs against
an unreviewed design.

Two consumers will not adopt it as-is, and that is correct:

• ksail / go-template use the tag-only shape → @devantler-tech/release-config/tag-only.json.
• world-at-ruin needs draftRelease: true (its releases must stay drafts until CD attaches the
  build), which the shared config does not express; it keeps its own config with the fix inlined.
  If more repos need that variant, a draft.json entry point is the natural follow-up.