ci: split out Nix CI; rename CI workflow to Rust CI

[AprilNEA]

Splits CI into two clearly-named workflows.

nix.yml (new — "Nix CI")

Builds the flake's .#openlogi package on macos-latest (nix build .#openlogi -L).

• Why: the Nix package's cargoHash goes stale whenever Cargo.lock changes (dep bump, release version bump, or a gpui pin bump) — a stale hash fails the build. This catches it automatically instead of surprising the next release/nixpkgs bump. (We just hit exactly this: 0.4.0 sha256-bY/… → 0.4.1 sha256-xtO1….)
• Gated to files that actually affect the Nix build (Cargo.lock, flake.*, nix/**, the committed .icns, the workflow itself), so it doesn't run on every Rust change — Rust CI covers those.
• darwin-only package; arm64 alone catches cargoHash drift (platform-independent).

ci.yml → display name "Rust CI"

Only the workflow's name: changed (CI → Rust CI). Job names are unchanged, so any required status checks are unaffected; the file and its triggers stay the same.

Uses DeterminateSystems/nix-installer-action@v22 (flakes on by default) + actions/checkout@v6.

cargoHash maintenance (nix/refresh-cargo-hash.sh)

The flake builds the working tree (local src), so nix-update can't refresh
the cargoHash — it tracks a remote version a local src doesn't have. Added
nix/refresh-cargo-hash.sh: it sets a fake hash, builds, and writes back the
value Nix reports (the vendor FOD fails before gpui compiles, so it's fast).
The nix.yml build above is the fail-closed guard; this script is the one-command fix.

Verified locally: nix build .#openlogi reports the committed cargoHash, and the
script round-trips to cargoHash already up to date.

Supersedes #133 (the remove-the-flake alternative) — keeping the flake with low-maintenance cargoHash instead of dropping it.

[pullfrog]

✅ No new issues found.

Reviewed changes — splits CI into two workflows: renames the existing ci.yml display name from "CI" to "Rust CI", and adds nix.yml that builds the flake .#openlogi on macos-latest, gated to files that actually affect the Nix build.

• Rename ci.yml name to "Rust CI" — job names unchanged (required status checks unaffected)
• New nix.yml — builds the Nix package with nix build .#openlogi -L, path-filtered to Cargo.lock, flake.nix, flake.lock, nix/**, the committed AppIcon.icns, and the workflow itself

All referenced paths exist in the repo. The flake exposes .#openlogi as expected. Standard actions (actions/checkout@v6, DeterminateSystems/nix-installer-action@v22). Clean, well-documented change — nothing to flag.

  ^{｜ View workflow run ｜ Using Big Pickle (free) (credentials for Anthropic not configured) ｜ 𝕏}

[greptile-apps]

Greptile Summary

This PR splits the monolithic CI workflow into two focused workflows — "Rust CI" (renamed ci.yml) and a new "Nix CI" (nix.yml) — and updates nix/package.nix to version 0.4.1 with a refreshed cargoHash and the rustPlatform.bindgenHook fix needed for the media/bindgen dependency.

• ci.yml: Only the name: field changes from CI to Rust CI; all jobs, triggers, and required-status-check names are untouched.
• nix.yml: New macOS-only workflow that runs nix build .#openlogi -L on pushes/PRs that touch Cargo.lock, flake.*, nix/**, the .icns, or the workflow file itself — providing automatic cargoHash drift detection without burning runner minutes on every Rust change.
• nix/package.nix: Version bump to 0.4.1, updated cargoHash to sha256-LXM+…, added rustPlatform.bindgenHook for libclang availability, and refined comments clarifying the local-src hash workflow vs. the future nixpkgs fetchFromGitHub form.

Confidence Score: 5/5

Safe to merge — changes are additive CI infrastructure and a routine Nix package maintenance update with no impact on the Rust build or application logic.

The ci.yml change is a one-word rename with zero functional impact. The new nix.yml workflow is well path-gated and only adds build coverage. The package.nix changes are maintenance: a version bump, a corrected cargoHash, a missing bindgenHook that was causing build failures, and comment clarifications. No application code, no migrations, no auth paths are touched.

No files require special attention. The new nix.yml workflow has no caching step, so each triggered build starts cold — but this is a cost/speed trade-off, not a correctness issue.

Important Files Changed

Filename	Overview
.github/workflows/ci.yml	Single-line name change: "CI" → "Rust CI". No functional changes to jobs, triggers, or steps.
.github/workflows/nix.yml	New workflow that builds the Nix flake package on macOS to catch stale cargoHash. Path-gated correctly; no caching step means cold builds on every trigger.
nix/package.nix	Version bump to 0.4.1, refreshed cargoHash, added rustPlatform.bindgenHook for libclang, and clarified comments on updateScript and hash reproducibility.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    push[Push / PR] --> rust_filter{Rust CI trigger\nany push/PR}
    push --> nix_filter{Nix CI trigger\npath-gated}

    rust_filter --> rust_jobs[rustfmt · clippy\ncheck-linux · test-linux\ntest-macos arm64/x86_64\ncheck-windows]

    nix_filter -->|Cargo.lock / flake.* / nix/**\n.icns / nix.yml changed| nix_job[nix build .#openlogi -L\nmacos-latest arm64]
    nix_filter -->|no matching paths| skip[Workflow skipped]

    nix_job --> pass{Build result}
    pass -->|success| ok[cargoHash fresh]
    pass -->|failure| fail[Logs print correct sha256\nUpdate cargoHash in package.nix]

Loading

_{Reviews (3): Last reviewed commit: "fix(nix): use the CI-computed cargoHash;..." | Re-trigger Greptile}

[greptile-apps]

Action tags are not SHA-pinned

actions/checkout@v6 and DeterminateSystems/nix-installer-action@v22 use floating version tags. If either tag is force-pushed to a different commit (accidentally or maliciously), the workflow silently picks up the new code with full runner permissions. Pinning to a commit SHA (e.g. actions/checkout@<sha>) eliminates this risk. This is consistent with ci.yml's existing pattern, but the new workflow is a good opportunity to tighten things up.

[greptile-apps]

No concurrency group — parallel macOS runs waste paid minutes

Without a concurrency group, rapid successive pushes to master (or a PR with multiple force-pushes) can queue several macOS jobs simultaneously. macOS runners are the most expensive in GitHub Actions; cancelling in-progress runs when a newer one starts keeps costs down.

Suggested change

	jobs:
	build:
	name: nix build (macOS)
	concurrency:
	group: nix-${{ github.ref }}
	cancel-in-progress: true
	jobs:
	build:
	name: nix build (macOS)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!