feat(release): embed digest-verified release notes in the release PR body#21
Conversation
…body The standing release PR body now carries the semantic-release notes the plan job already generates, so the maintainer sees what ships before merging. The notes travel through the existing artifact and are verified against a new notes-sha256 plan output, commit-derived HTML comment openers are neutralized so the provenance marker stays the body's only marker-shaped comment, and oversized notes truncate below GitHub's body limit. Marker extraction in release-validate and release now requires exactly one match instead of first-match-anywhere, so a decoy marker in a commit message fails loudly instead of confusingly.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e793af98d4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Neutralizing only comment openers left tags like an unclosed <details><summary> active, which could visually hide the generated boilerplate from the human reviewer. The notes generator emits pure markdown, so escaping every '<' only affects commit-derived text. Addresses Codex review feedback on #21.
|
@codex review |
|
Codex Review: Didn't find any major issues. Chef's kiss. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Picks up chhoumann/obsidian-plugin-workflows#21: release PR bodies now embed the digest-verified release notes, and provenance marker parsing requires exactly one match.
Makes the standing release PR informative: the body now embeds the release notes the plan job already generates, so the maintainer sees what ships before merging (previously the body was only the "Prepare X from tested commit" boilerplate, e.g. chhoumann/quickadd#1525).
How the notes get there. The plan job emits a
notes-sha256output; the open-pr script readsrelease-notes.mdfrom the already-downloaded artifact and verifies it against that digest, same as the version files - everything in the PR body traces to the plan job through the trusted output channel. The notes' own heading already carries previous/next version, compare link, and date, so no extra summary lines were added.Hardening that comes with it. The notes derive from commit messages, so the body is no longer fully machine-controlled text:
<!--becomes<!--, which renders identically), so a commit subject cannot plant a decoy provenance marker or hide rendered body text behind an unclosed comment.release-validate.ymlandrelease.ymlnow requires exactly one match instead of first-match-anywhere. A decoy marker could never forge a release (the base SHA is cross-checked against the head commit's parent), but it could brick validation confusingly; ambiguity now fails with a clear error. Old-format bodies on already-open release PRs still validate: they contain exactly one marker.Review focus. The open-pr script changes in
release-prepare.yml(digest check, sanitization, body assembly) and whether the unique-marker rule in the two validators could reject any legitimate existing PR shape.Tests run the real open-pr script extracted from the workflow YAML; new cases cover sanitization + marker uniqueness, truncation, and digest-mismatch rejection. The threat-model doc gains a bullet for the new invariant.