chore(release): append en.dev sponsor blurb to release notes by jdx · Pull Request #431 · jdx/fnox

jdx · 2026-04-23T16:45:34Z

Summary

Appends a Sponsor fnox section to every GitHub Release body, run after communique generate in the enhance-release job in .github/workflows/release.yml.
Same pattern as mise#9272, adapted for fnox.

What it looks like

Rendered at the bottom of each release body:

💚 Sponsor fnox

fnox is maintained by @jdx under en.dev — a small independent studio building developer tooling like mise, aube, hk, and more. Keeping fnox secure, maintained, and free is funded by sponsors.

If fnox is handling secrets or config for you or your team, please consider sponsoring at en.dev. Sponsorships are what let fnox stay independent and the project keep moving.

Test plan

`actionlint` + `yamllint` pass on the modified workflow
Next tagged release produces a GitHub Release whose body ends with the sponsor section

🤖 Generated with Claude Code

Adds a "Sponsor fnox" section at the bottom of each GitHub Release body after communique generates the narrative notes, so readers who land on a release see how fnox is funded and where to sponsor. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

gemini-code-assist · 2026-04-23T16:45:40Z

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

greptile-apps · 2026-04-23T16:47:21Z

Greptile Summary

This PR adds a sponsor blurb append step to the enhance-release workflow job and refactors TUI match arms in app.rs and event.rs to use match guard syntax. The workflow change is straightforward; the Rust changes are mostly clean, except that event.rs encodes side effects (channel sends) inside match guards rather than arm bodies.

Confidence Score: 5/5

Safe to merge — only one P2 style finding in event.rs; all logic is functionally correct.

The workflow change is correct and the Rust refactors are functionally equivalent. The single flagged issue (side effects in match guards in event.rs) does not affect runtime behavior and is a style concern only.

src/tui/event.rs — the match-guard side-effect pattern warrants a second look, though it is not a bug today.

Important Files Changed

Filename	Overview
.github/workflows/release.yml	Adds a new "Append en.dev sponsor blurb" step to the enhance-release job that reads the current release body, appends the sponsor section via heredoc, and writes it back with `gh release edit`.
src/tui/app.rs	Refactors several match arms to lift inner `if` conditions into match guards — semantically equivalent, cleaner code. No logic changes.
src/tui/event.rs	Refactors event-dispatch match arms to use match guards with side-effectful send() calls as the guard predicate — functionally correct but unconventional and could confuse future maintainers.

Sequence Diagram

sequenceDiagram
    participant GH as GitHub Tag Push
    participant BB as build-binaries
    participant CR as create-release
    participant ER as enhance-release

    GH->>BB: trigger on push/tag
    BB-->>CR: artifacts uploaded
    CR->>CR: extract CHANGELOG notes
    CR->>CR: gh release create (with assets)
    CR-->>ER: release created
    ER->>ER: communique generate (AI-enhanced notes)
    ER->>ER: gh release view (fetch body)
    ER->>ER: append sponsor blurb via heredoc
    ER->>GH: gh release edit (write final notes)

_{Reviews (3): Last reviewed commit: "[autofix.ci] apply automated fixes (atte..." | Re-trigger Greptile}

greptile-apps · 2026-04-23T16:47:26Z

+          {
+            gh release view "$TAG_NAME" --json body --jq .body
+            cat <<'EOF'


Non-idempotent append on workflow re-run

The step always appends the sponsor blurb to whatever gh release view returns at that moment. If the enhance-release job (or just this step) is re-run — due to a transient failure, a manual retry, or a re-triggered release — the section will be appended a second time. Adding an idempotency guard prevents this:

Suggested change

{

gh release view "$TAG_NAME" --json body --jq .body

cat <<'EOF'

BODY=$(gh release view "$TAG_NAME" --json body --jq .body)

if echo "$BODY" | grep -qF '## 💚 Sponsor fnox'; then

echo "Sponsor blurb already present, skipping."

exit 0

fi

{

echo "$BODY"

cat <<'EOF'

The provider codegen in build/generate_providers.rs sorted providers by category only. Stable sort preserves input order for equal keys, and fs::read_dir returns entries in OS-dependent order, so providers within the same category were ordered by whatever the filesystem produced. That non-determinism flowed into the generated ProviderConfig enum and then into docs/public/schema.json, causing autofix.ci to produce schema diffs that flip 100+ lines back and forth between runs (see #431 where three autofix passes kept reshuffling the same oneOf variants). Add a secondary sort by provider name so within-category ordering is deterministic, and regenerate docs/public/schema.json. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

## Summary - Providers within a category were ordered by `fs::read_dir` (OS/filesystem-dependent). - That non-determinism flowed into the generated `ProviderConfig` enum and then into [docs/public/schema.json](docs/public/schema.json), causing [autofix.ci](https://github.com/jdx/fnox/blob/main/.github/workflows/autofix.yml) to keep reshuffling 100+ lines between runs. You can see this on [#431](#431) — three autofix passes each re-ordered the same `oneOf` variants without converging. - Adds a secondary sort by provider name in [`build/generate_providers.rs`](build/generate_providers.rs) so within-category ordering is fully deterministic, then regenerates [docs/public/schema.json](docs/public/schema.json) with the stable ordering. ## Root cause ```rust // before — stable sort on category only; within-category order = read_dir order providers.sort_by(|a, b| cat_order(&a.1.category).cmp(&cat_order(&b.1.category))); ``` Stable sort preserves input order on ties, and input order comes from `fs::read_dir`, which is not guaranteed to be sorted. Fix is a secondary `.then_with(|| a.0.cmp(&b.0))` on name. ## Test plan - [x] `mise run render:schema` locally - [x] Running `fnox schema` twice produces byte-identical output - [ ] `autofix.ci` on this PR does not re-touch `docs/public/schema.json` - [ ] Future PRs that don't touch provider definitions should not see schema churn 🤖 Generated with [Claude Code](https://claude.com/claude-code)  --- > [!NOTE] > **Low Risk** > Low risk: only changes provider sorting in a build-time codegen script and regenerates `docs/public/schema.json`; no runtime logic or security-sensitive behavior is modified. > > **Overview** > Ensures provider definitions are loaded in a *fully deterministic* order during schema/code generation by sorting first by category and then by provider name (avoiding OS/filesystem-dependent `read_dir` ordering). > > Regenerates `docs/public/schema.json` so the `ProviderConfig` `oneOf` variants appear in stable order, eliminating cross-machine/CI churn in the generated schema output. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 291cd31. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup>  Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

@bglusman

@bglusman

@jdx

## Summary - Appends a **Sponsor fnox** section to every GitHub Release body, run after `communique generate` in the `enhance-release` job in [`.github/workflows/release.yml`](.github/workflows/release.yml). - Same pattern as [mise#9272](jdx/mise#9272), adapted for fnox. ## What it looks like Rendered at the bottom of each release body: > ## 💚 Sponsor fnox > > fnox is maintained by [@jdx](https://github.com/jdx) under [**en.dev**](https://en.dev) — a small independent studio building developer tooling like [mise](https://mise.jdx.dev/), [aube](https://aube.en.dev/), hk, and more. Keeping fnox secure, maintained, and free is funded by sponsors. > > If fnox is handling secrets or config for you or your team, please consider [sponsoring at en.dev](https://en.dev). Sponsorships are what let fnox stay independent and the project keep moving. ## Test plan - [x] \`actionlint\` + \`yamllint\` pass on the modified workflow - [ ] Next tagged release produces a GitHub Release whose body ends with the sponsor section 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>

) ## Summary - Providers within a category were ordered by `fs::read_dir` (OS/filesystem-dependent). - That non-determinism flowed into the generated `ProviderConfig` enum and then into [docs/public/schema.json](docs/public/schema.json), causing [autofix.ci](https://github.com/jdx/fnox/blob/main/.github/workflows/autofix.yml) to keep reshuffling 100+ lines between runs. You can see this on [jdx#431](jdx#431) — three autofix passes each re-ordered the same `oneOf` variants without converging. - Adds a secondary sort by provider name in [`build/generate_providers.rs`](build/generate_providers.rs) so within-category ordering is fully deterministic, then regenerates [docs/public/schema.json](docs/public/schema.json) with the stable ordering. ## Root cause ```rust // before — stable sort on category only; within-category order = read_dir order providers.sort_by(|a, b| cat_order(&a.1.category).cmp(&cat_order(&b.1.category))); ``` Stable sort preserves input order on ties, and input order comes from `fs::read_dir`, which is not guaranteed to be sorted. Fix is a secondary `.then_with(|| a.0.cmp(&b.0))` on name. ## Test plan - [x] `mise run render:schema` locally - [x] Running `fnox schema` twice produces byte-identical output - [ ] `autofix.ci` on this PR does not re-touch `docs/public/schema.json` - [ ] Future PRs that don't touch provider definitions should not see schema churn 🤖 Generated with [Claude Code](https://claude.com/claude-code)  --- > [!NOTE] > **Low Risk** > Low risk: only changes provider sorting in a build-time codegen script and regenerates `docs/public/schema.json`; no runtime logic or security-sensitive behavior is modified. > > **Overview** > Ensures provider definitions are loaded in a *fully deterministic* order during schema/code generation by sorting first by category and then by provider name (avoiding OS/filesystem-dependent `read_dir` ordering). > > Regenerates `docs/public/schema.json` so the `ProviderConfig` `oneOf` variants appear in stable order, eliminating cross-machine/CI churn in the generated schema output. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 291cd31. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup>  Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

@bglusman

@bglusman

greptile-apps Bot reviewed Apr 23, 2026

View reviewed changes

autofix-ci Bot added 2 commits April 23, 2026 16:54

[autofix.ci] apply automated fixes

5411540

[autofix.ci] apply automated fixes (attempt 2/3)

0bfdf1a

jdx enabled auto-merge (squash) April 23, 2026 17:07

jdx disabled auto-merge April 23, 2026 17:09

jdx enabled auto-merge (squash) April 23, 2026 17:09

jdx disabled auto-merge April 23, 2026 17:09

jdx enabled auto-merge (squash) April 23, 2026 17:10

jdx mentioned this pull request Apr 23, 2026

fix(build): deterministic provider ordering in generated schema #432

Merged

4 tasks

jdx merged commit 151720f into main Apr 23, 2026
14 checks passed

jdx deleted the claude/sponsor-blurb-release-notes branch April 23, 2026 17:25

mise-en-dev mentioned this pull request Apr 23, 2026

chore: release v1.22.0 #433

Merged

mise-en-dev mentioned this pull request Apr 26, 2026

chore: release v1.23.0 #445

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

chore(release): append en.dev sponsor blurb to release notes#431

chore(release): append en.dev sponsor blurb to release notes#431
jdx merged 3 commits intomainfrom
claude/sponsor-blurb-release-notes

jdx commented Apr 23, 2026

Uh oh!

gemini-code-assist Bot commented Apr 23, 2026

Uh oh!

greptile-apps Bot commented Apr 23, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot Apr 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

-          {
-            gh release view "$TAG_NAME" --json body --jq .body
-            cat <<'EOF'
+          BODY=$(gh release view "$TAG_NAME" --json body --jq .body)
+          if echo "$BODY" | grep -qF '## 💚 Sponsor fnox'; then
+            echo "Sponsor blurb already present, skipping."
+            exit 0
+          fi
+          {
+            echo "$BODY"
+            cat <<'EOF'

Uh oh!

Conversation

jdx commented Apr 23, 2026

Summary

What it looks like

💚 Sponsor fnox

Test plan

Uh oh!

gemini-code-assist Bot commented Apr 23, 2026

Uh oh!

greptile-apps Bot commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Sequence Diagram

Uh oh!

greptile-apps Bot Apr 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

greptile-apps Bot commented Apr 23, 2026 •

edited

Loading