Skip to content

fix(ci): pass release notes by file, not shell interpolation - #4

Merged
flaccid merged 3 commits into
mainfrom
ci/fix-release-notes-file
Aug 25, 2026
Merged

fix(ci): pass release notes by file, not shell interpolation#4
flaccid merged 3 commits into
mainfrom
ci/fix-release-notes-file

Conversation

@flaccid

@flaccid flaccid commented Aug 25, 2026

Copy link
Copy Markdown
Member

The first real release (v0.2.1) published notes with every code span and the
fenced code block silently removed:

1 commit(s) since  — 1 feature(s).
> The 1 commit(s) since  are CI, tooling and documentation only. This version
> exists to keep the components aligned: the Helm chart's  pins all four images

${{ steps.notes.outputs.body }} interpolates the text into the shell script,
so bash treats the backticks as command substitution and executes them. Every
code span became empty and the fenced block vanished.

The preamble is already written to /tmp/preamble.md, so this uses
--notes-file and drops the GITHUB_OUTPUT round-trip entirely.

The generator itself was correct — the dry-run summaries rendered properly, which
is what isolated the fault to the publishing step. The v0.2.1 release bodies have
been corrected by hand; releases from v0.2.2 onward will render correctly
unattended.

Same fix applied across all five repositories.

The first real release published notes with every `code span` and the fenced code
block silently removed: `${{ steps.notes.outputs.body }}` interpolates the text
into the shell script, so bash treats the backticks as command substitution and
executes them.

The preamble is already on disk, so use --notes-file and drop the GITHUB_OUTPUT
round-trip. The generator itself was correct — the dry-run summaries rendered
properly, which isolated the fault to the publishing step.

Same fix applied across all five repositories.
@flaccid flaccid added bug Something isn't working ci CI, build and release tooling labels Aug 25, 2026
The first real release tagged v0.2.1 but published no versioned image. A tag
pushed with GITHUB_TOKEN does not trigger other workflows — GitHub suppresses
that to prevent recursion — so docker.yml never fired despite its `tags: ["v*"]`
trigger.

That matters beyond the missing tag: kube-workspaces/deploy's release workflow
refuses to release unless a matching image exists for all four components, so the
whole chain would stall.

Dispatch the build explicitly once the release is created. The v0.2.1 images were
built by hand; from v0.2.2 onward this is unattended.
Actions evaluates expressions everywhere in a workflow file, including inside
comments. The placeholder in the previous commit's explanatory comment was not
valid expression syntax, so the file failed to parse and the workflow became
undispatchable — it registered by filename rather than by name.

Caught in kube-workspaces/deploy before this branch merged.
@flaccid
flaccid merged commit 5569ff3 into main Aug 25, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working ci CI, build and release tooling

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant