ci: build the flake in a non-gating job (task 0041) #50
Reference in New Issue
Block a user
Delete Branch "task-0041-ci-flake-build-job"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Task:
.claude/tasks/0041-ci-flake-build-job.mdSummary
Adds a distinct
flakejob to.gitea/workflows/ci.ymlthat runsnix flake check --print-build-logson push and on pull request.Its value is detecting flake rot — most concretely a build-relevant file left out of
package.nix's source allowlist — at the commit that causes it, rather than weeks later at the maintainer's next system rebuild.The job is non-gating by two mechanisms, both needed: no
needsedge, so it neither waits on thetestjob nor is waited on, andcontinue-on-error, so a red build does not fail the workflow run and therefore cannot block a merge.Its cost — a cold rebuild of the whole dependency closure, plus a re-run of the fast tier and the installed-binary tier inside the derivation — is stated in the workflow comment alongside the non-gating intent, so neither reads as an oversight.
The allowlist criterion was verified rather than assumed: deleting
./tsconfig.build.jsonfrompackage.nix'slib.fileset.unionsand re-runningnix flake checklocally fails the build witherror TS5058: The specified path does not exist: 'tsconfig.build.json'.package.nixwas restored immediately; the probe is not in the diff.Deviations
continue-on-errorsits on the steps, not the job. The obvious spelling was a job key, and the first draft had it there. Gitea'sactfork declaresRawContinueOnErroron itsStepstruct only — theJobstruct has no such field — so a job-level flag is parsed as an unknown key and silently dropped, and a failing check would have failed the run after all: exactly the merge-blocking outcome the criterion forbids, with nothing in the logs to explain it. Gitea's own syntax-comparison page does not list the gap. Step-level is honoured by bothactand GitHub Actions, so the fix costs no portability. Recorded as a Gotcha inCLAUDE.md.Two incidental fixes. The file header comment said "The job runs inside a node container" — singular, and false once a second job exists that deliberately runs without one; now scoped to "The
testjob". The build step is named "Check the flake (builds the package)" rather than "Build the flake", so the label and the command agree without needing the adjacent comment read first.Review
Risk
Overall: LOW
Unaddressed findings
Standards —
cachix/install-nix-action@v31is pinned to a mutable major tag. Left as is: it matches howactions/checkout@v4is pinned elsewhere in the file, and pinning one action by commit SHA while the rest use tags would be inconsistent without being materially safer for a non-gating job that holds no credentials and nosecretsaccess. Worth revisiting as a file-wide decision rather than a local one.Spec —
nix flake checkbuilds only the runner's own system.aarch64-linuxandaarch64-darwinare evaluated but not built;--all-systemswould not change that, since building them needs runners of those architectures. Left as is: the job's value is the allowlist guard, which is architecture-independent, so this is a limit rather than a shortfall.