ci: auto-sync bun.nix when a PR changes bun.lock - #79
Merged
Conversation
bun.nix is generated from bun.lock (bun2nix) and consumed by the flake's frontend build. Contributors not on Nix — or who forget `bunx bun2nix` — would land a bun.lock change with a stale bun.nix and break the nix build. New workflow regenerates bun.nix on PRs that touch bun.lock and pushes a chore commit ONLY when the result actually differs from what's committed (regenerate → `git diff --quiet -- bun.nix` → no drift, no commit). Guarded to same-repo PRs (fork GITHUB_TOKEN can't push back); bun2nix pinned to the flake's 2.1.0 so the output format always matches fetchBunDeps.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
bun.nixis the generated Nix mirror ofbun.lock(the flake's frontend build reconstructsnode_modulesfrom it viabun2nix.fetchBunDeps, seenix/desktop.nix). A contributor who isn't on Nix — or who just forgets to runbunx bun2nix— can land abun.lockchange with a stalebun.nixand break the nix build (exactly what happened in #77 until it was caught manually).New workflow
.github/workflows/sync-bun-nix.yml:bun.lock(first "is it needed" gate).bunx bun2nix@2.1.0(pinned to the versionflake.nixlocks, so the output format always matchesfetchBunDeps).git diff --quiet -- bun.nix; if the file is already in sync (author ran bun2nix themselves, or the lock change didn't affect the Nix output) it does nothing (second gate). Otherwise it pushes onechore(nix): sync bun.nix with bun.lockcommit onto the PR branch.Affected layer
frontend/— React Web UIcrates/·src-tauri/— Rust core / backend / Tauri desktopmodule/— Android installable zip (thin launcher over the Rust daemon)scripts/— build / release helpers.github/Verification
actionlint 1.7.12clean on the new workflow (same versionlint-workflows.ymlpins)bunx bun2nix@2.1.0 --output-file bun.nixreproduces the committed file locally (verified while preparing feat(profiles): reorder groups via drag-and-drop #77)ci.yml(actions/checkoutv4,oven-sh/setup-bunv2).Checklist
Notes for reviewers
GITHUB_TOKEN, and GitHub does not trigger workflows fromGITHUB_TOKENpushes — so the bot commit cannot re-trigger this (or any) workflow. Thegit diff --quietgate is a second guard regardless.GITHUB_TOKENis read-only for fork PRs, so pushing back is impossible there. The job isif-guarded to same-repo PRs; on forks the regular nix build still fails loudly on drift, prompting the author to runbunx bun2nix. (A fork-friendly variant would post a comment instead — happy to add if wanted.)GITHUB_TOKEN, other checks won't auto re-run on the sync commit. That's the deliberate trade-off for loop safety (a PAT would re-run CI but reintroduce loop risk and token management).flake.nixbumps thebun2nixref, bump thebunx bun2nix@<ver>pin in this workflow too (noted in an inline comment).