[Exypte]

What type of PR is this?

ci

What this PR does / why we need it:

propagate.yml copied the GitHub release body into the component's RELEASE_NOTES.md, and the GitLab tag pipeline published it as is. Every GitLab Catalog release therefore listed the whole CLI changelog. For example, v0.7.11 lists the workflow lockfile control and a github-actions bump, while the only change to the component is the image digest.

The notes are now built by scripts/release-component-notes.sh, in the Keep a Changelog 1.1.0 format (following p1-dta's note on the issue):

## [0.7.12] - 2026-10-26

### Changed

- Image bumped to `getplumber/plumber:0.7.12` (`sha256:fe07…fd53`).

The full CLI changelog is in the [v0.7.12 GitHub release](https://github.com/getplumber/plumber/releases/tag/v0.7.12).

[0.7.12]: https://gitlab.com/getplumber/plumber/-/compare/v0.7.11...v0.7.12

• Image: always listed under Changed, with the digest propagate already resolves.
• Template commits: each commit touching templates/ between the previous tag and this one becomes an entry: feat → Added, fix → Fixed, deprecate → Deprecated, remove/drop → Removed, security type or scope → Security, anything else → Changed. A breaking change gets a **Breaking:** prefix. Empty sections are left out.
• Links: to the GitHub release for the full CLI changelog, and a GitLab compare between the component tags.

Which issue(s) this PR is related to:

Fixes #569

Special notes for your reviewer:

• Release commits are skipped by their (release) scope, which covers today's chore(release) and the older ci(release): pin … commits. Their only template change is the digest bump, already covered by the image entry.
• The date is the tag's commit date, so a re-dispatch writes the same notes.
• GH_TOKEN is gone from the "Resolve release refs" step: nothing in it calls gh any more.
• COMPONENT_URL / CLI_URL default to getplumber's GitLab and GitHub projects. CLI_URL comes from the workflow context; COMPONENT_URL is only overridden by the e2e lab below.
• No extra "CLI changes affecting GitLab" section (the issue's optional idea). Keep a Changelog has no such type, and the GitHub release link covers it.

Does this PR introduce a user-facing change?

The GitLab CI/CD Catalog release notes of the component now describe only the component's changes (image digest, template changes), in the Keep a Changelog format, and link to the GitHub release for the full CLI changelog.

How was this tested?

• scripts/release-component-notes.test.sh (27 cases, wired into scripts-test.yml). It covers: first release with no previous tag, version sort (v0.7.9 < v0.7.10), a digest-only release, every section and its order, breaking markers, release and CLI-only commits left out, URL overrides, and bad inputs. The four existing release script tests still pass.
• E2E on real CI: a lab copy of propagate.yml in getplumber-examples/release-propagate-lab, pushing to thibaultcondemine/component-release-lab, with the real templates and digests of v0.7.9 to v0.7.12.
  • Before (main's propagate): the GitLab releases carried the full CLI changelog. v0.7.12 listed a GitHub-only fix and missed the two template commits.
  • After (this branch, the only change in the lab): v0.7.10 and v0.7.11 show only the image line. v0.7.12 shows Added + Changed + Fixed, with the GitHub-only commits left out.
  • v0.7.13 was cut by a minimal lab release workflow calling propagate as release.yml does (run, GitLab release).

AI usage disclosure:

YES. Written with Claude Code (script, tests, workflow change, e2e lab). The author reviewed the changes and is responsible for them.

🤖 Generated with Claude Code

[github-actions]

🔴 Bug risks

Low: the Removed-section classifier grep -qiE '^(remove|drop)' matches any subject whose first word merely starts with "remove"/"drop", so additions like "dropdown"/"drop-in" are listed as removals. (Low)

The regex ^(remove|drop) has no word boundary, so it matches any description beginning with those letters, not just the words remove/drop. This check runs before the feat/fix type checks and on every commit regardless of type.

Concrete failure: a template-touching commit feat(component): dropdown selector for report format (or feat(component): drop-in replacement for X) has desc="dropdown selector for report format". ^(remove|drop) matches the leading drop of "dropdown", so the entry is appended to removed+=(...) at line 75 and the GitLab component release notes show the new feature under ### Removed — telling component users a capability was removed when it was actually added.

The header comment documents the intent as "subject starting remove/drop", i.e. the words remove/drop, so this is an implementation gap rather than a documented trade-off. Anchoring to a word boundary fixes it, e.g. ^(remove|drop)(\b|[[:space:]]|$) (or ^(remove|removes|removed|drop|drops|dropped|dropping) ). Note the Deprecated check on line 72 (grep -qi 'deprecat') is explicitly documented as matching anywhere ("subject saying deprecate"), so it is intentional and not part of this finding.

_{Control: .github/claude-prompts/bug-risks.md · resolve this conversation once addressed.}

[github-actions]

🔴 Test coverage

Low: the security-by-type classification branch is never exercised by a test — only the security-by-scope branch is. (Low)

The section classifier in scripts/release-component-notes.sh:70 routes a commit to Security when either its conventional-commit type is security or its scope contains security:

if [ "$type" = "security" ] || [[ ",${scope}," =~ ,[[:space:]]*security[[:space:]]*, ]]; then

The test suite only covers the scope branch — scripts/release-component-notes.test.sh:230 commits fix(component,security): do not echo the token and asserts it lands under ### Security. There is no test for a security-typed commit (e.g. security: patch the token leak or security(component): rotate keys), even though the script's own header comment documents this mapping ("security type or scope -> Security", scripts/release-component-notes.sh:17).

Because the [ "$type" = "security" ] disjunct is never executed, a regression affecting only that branch — a typo, or a refactor that collapses the condition to scope-only — would silently misclassify security-typed commits into the Changed section, producing incorrect GitLab component release notes, and the full test run would still report all tests passed.

Suggested test: add a commit commit templates/plumber.yml "security: patch the token leak" (plain security type, no scope) before the v0.8.0 release in the section-coverage block, and assert its description appears under ### Security (and does not appear under ### Changed). This closes the second, currently-unverified half of the Security routing logic.

_{Control: .github/claude-prompts/test-coverage.md · resolve this conversation once addressed.}