Skip to content

fix(ci): de-duplicate sponsor section in release notes#459

Merged
jdx merged 1 commit intomainfrom
fix-release-double-sponsor
May 2, 2026
Merged

fix(ci): de-duplicate sponsor section in release notes#459
jdx merged 1 commit intomainfrom
fix-release-double-sponsor

Conversation

@jdx
Copy link
Copy Markdown
Owner

@jdx jdx commented May 2, 2026

Summary

v1.23.1 shipped with two Sponsor fnox sections back-to-back. Cause: the enhance-release job in release.yml always appends a canonical sponsor block, and communique had also written one into the body — it picked up the pattern from prior releases passed in as "Style Reference" (which themselves contain the appended block).

Two changes:

  • communique.toml: add a system_extra directive telling the LLM not to include a sponsor section in the body — that's the workflow's job.
  • .github/workflows/release.yml: make the append step idempotent. Strip any pre-existing ## ... Sponsor fnox section from the generated body (heading through next ## , or to EOF) before appending the canonical block. Even if a future generation slips one in, the published release ends up with exactly one.

The v1.23.1 release notes have already been edited to remove the duplicate.

Test plan

  • Awk filter strips both ## Sponsor fnox and ## 💚 Sponsor fnox sections (verified locally against a synthetic body).
  • Awk filter is a no-op on a body with no sponsor section (verified locally).
  • mise run lint clean (actionlint + prettier).
  • Next release produces a single sponsor section.

🤖 Generated with Claude Code


Note

Low Risk
Low risk CI/release-workflow changes only; main risk is accidentally stripping unintended sections from release notes if headings match the awk pattern.

Overview
Prevents duplicate sponsor blurbs in published GitHub releases by making the enhance-release append step idempotent: it now removes any existing ## … Sponsor fnox section from the current release body before appending the canonical block.

Updates communique.toml with extra system instructions to avoid generating any sponsorship/support section in the first place, since the workflow is responsible for adding it.

Reviewed by Cursor Bugbot for commit 86b336e. Bugbot is set up for automated code reviews on this repo. Configure here.

The enhance-release workflow appends a canonical "Sponsor fnox" block to
every release. communique was also producing one in the body it generates
(modeling it on prior releases shown via "Style Reference"), so v1.23.1
ended up with both — see https://github.com/jdx/fnox/releases/tag/v1.23.1
before the manual fix.

- Tell communique not to write a sponsor section via system_extra in
  communique.toml — that's the workflow's job.
- Make the workflow idempotent: strip any existing "## ... Sponsor fnox"
  section from the body before appending the canonical one, so a future
  generation that includes one anyway still produces a single block.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@jdx jdx force-pushed the fix-release-double-sponsor branch from 18cb246 to 86b336e Compare May 2, 2026 19:26
@jdx jdx enabled auto-merge (squash) May 2, 2026 19:26
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the project into a Cargo workspace, extracting core secret management logic into a new fnox-core library crate. The fnox binary now depends on this library and re-exports its modules, while dependency management has been centralized in the workspace manifest. Feedback suggests defining the internal fnox-core dependency within the workspace configuration for better maintainability and correcting documentation in the core crate that still references modules moved to the binary.

I am having trouble creating individual review comments. Click here to see my feedback.

Cargo.toml (110)

medium

For better maintainability and consistency within the workspace, consider defining the fnox-core dependency in the [workspace.dependencies] section and inheriting it here using workspace = true. This centralizes the version and path configuration for internal crates, making it easier to manage as the workspace grows. Note that this change requires adding fnox-core = { path = "crates/fnox-core", version = "1.23.0" } to the [workspace.dependencies] section.

fnox-core = { workspace = true }

crates/fnox-core/src/library.rs (4-16)

medium

The documentation in the fnox-core crate still contains references to the commands module (e.g., commands::get::GetCommand::run and commands::set::SetCommand::run), which has been moved to the fnox binary crate. Since fnox-core is now a separate library, these internal references are broken and may be confusing for users of the library. It is recommended to update these comments to describe the logic abstractly or refer to the fnox crate explicitly.

@greptile-apps
Copy link
Copy Markdown

greptile-apps Bot commented May 2, 2026

Greptile Summary

Fixes duplicate ## 💚 Sponsor fnox sections in release notes by (1) adding a system_extra directive in communique.toml telling the LLM not to emit a sponsor block, and (2) making the workflow's append step idempotent with an awk filter that strips any pre-existing sponsor heading before appending the canonical block.

The awk pattern /^## .*Sponsor fnox[[:space:]]*$/ correctly matches both ## Sponsor fnox and ## 💚 Sponsor fnox, and YAML block-scalar processing strips the common indentation before the shell runs, so the regex anchors work as expected against the previously appended block. Both changes together are a solid belt-and-suspenders approach.

Confidence Score: 5/5

Safe to merge — targeted fix with correct logic and no regressions introduced.

Both changes are small, well-scoped, and correct. The awk filter handles all known sponsor heading formats, YAML indentation stripping ensures the regex anchors work against the workflow's own previously-appended block, and the communique directive provides the primary prevention layer. No functional regressions found.

No files require special attention.

Important Files Changed

Filename Overview
.github/workflows/release.yml Refactors the sponsor-block append step to first awk-strip any pre-existing "Sponsor fnox" heading (and its body) from the release notes before appending the canonical block, making the step idempotent.
communique.toml Adds a system_extra directive instructing the LLM not to emit a sponsor section, since the workflow appends the canonical block itself.

Sequence Diagram

sequenceDiagram
    participant CQ as communique (LLM)
    participant GH as GitHub Release API
    participant AWK as awk filter
    participant TMP as /tmp/release-notes.md
    participant GHE as gh release edit

    Note over CQ: system_extra: do NOT add sponsor section
    CQ->>GH: generate release notes (no sponsor section)
    GH-->>GH: release body stored

    Note over GH,AWK: "Append en.dev sponsor blurb" step
    GH->>AWK: gh release view --json body --jq .body
    AWK->>AWK: strip any ## .*Sponsor fnox section
    AWK->>TMP: write cleaned body
    TMP->>TMP: cat >> canonical sponsor block
    TMP->>GHE: gh release edit --notes-file
    GHE-->>GH: exactly one sponsor section published
Loading

Reviews (1): Last reviewed commit: "fix(ci): de-duplicate sponsor section in..." | Re-trigger Greptile

@jdx jdx merged commit 156d42b into main May 2, 2026
16 checks passed
@jdx jdx deleted the fix-release-double-sponsor branch May 2, 2026 19:34
jdx pushed a commit that referenced this pull request May 6, 2026
### 🚀 Features

- **(github-oauth)** add github oauth lease backend by
[@jdx](https://github.com/jdx) in
[#464](#464)

### 🐛 Bug Fixes

- **(ci)** de-duplicate sponsor section in release notes by
[@jdx](https://github.com/jdx) in
[#459](#459)

### 🔍 Other Changes

- **(ci)** use !cancelled() instead of always() for final job by
[@jdx](https://github.com/jdx) in
[#461](#461)
- set dev profile debug to 1 by [@jdx](https://github.com/jdx) in
[#462](#462)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant