Archived

This repository has been archived on 2026-07-30. You can view files and clone it. You cannot open issues or pull requests or push a commit.

Files

T

beatzaplenty 7e9c0c2a6f

Check NixOS configurations / eval-hosts (pull_request) Canceled after 0s

Details

Rewrite codex-maintenance.sh to scope CI checks to changed files

CI was running a full eval of every host + package on every push/PR,
which was slow enough to routinely time out the Gitea runner. Default
mode now diffs against a base ref and scopes nixpkgs-fmt/statix/eval to
the files that changed and the hosts/packages they can affect; a change
to flake.nix/flake.lock/variables.nix/modules/common/* (or any other
modules/*.nix outside platforms//build-types, whose blast radius isn't
inferable from the path) falls back to evaluating everything. The old
full sweep moves behind --full-check, which CI never passes; --dry-run
adds build-planning on top of whichever scope is active.

Also trims codex-setup.sh's redundant full host eval loop -- that's
what codex-maintenance.sh is for; setup should just install tooling.

2026-07-20 17:25:22 +00:00

3.8 KiB

Raw Permalink Blame History

flake.lock automation

This repository uses CI workflows to keep flake.lock up to date on a schedule and to verify that declared NixOS hosts still evaluate after dependency updates.

What this automation does

A scheduled workflow runs nix flake update once per week.
On GitHub, any resulting flake.lock change is proposed through a pull request.
On Gitea, the workflow can commit and push flake.lock directly when PR automation is not configured.
A separate CI workflow runs scripts/codex-maintenance.sh before merge. Its default mode scopes eval to the hosts/packages a change can affect, determined from a git diff against the PR base — but a flake.lock change is treated as repo-wide and always falls back to evaluating every host, so a lock-file update PR still gets full coverage. Hosts are still listed dynamically via nix eval --json .#nixosConfigurations --apply builtins.attrNames rather than hand-enumerated, so that fallback can't drift as <platform>-<buildtype> targets are added or removed. See README.md for the current target list.

Why hosts should stop using `--upgrade-all`

flake.lock is the source of truth for pinned dependency versions in a flake-based workflow. Normal host rebuilds should consume the committed lock file instead of upgrading dependencies ad-hoc on each machine.

Recommended rebuild command:

sudo nixos-rebuild switch --flake git+https://gitea.lan.ddnsgeek.com/beatzaplenty/nixos.git#$(cat /etc/flake-target)

Flake attribute names are <platform>-<buildtype> (e.g. proxmox-docker) and no longer match hostname, since a host's hostname stays fixed while the platform backing it can change. Each nixosConfiguration stamps its own active target name into /etc/flake-target at build time, which is what the command above reads.

Using the committed lock file keeps all hosts aligned and makes updates auditable through CI and code review.

Codex and automated review sessions must not run rebuilds. Limit checks to evaluation, linting, formatting, and dry-run builds.

Command differences

nix flake update
- Updates flake input pins in flake.lock.
- Should be run in CI or in a dedicated update PR workflow.
nixos-rebuild --upgrade
- Primarily for channel-based workflows; not the normal path for flake-pinned deployments.
nixos-rebuild --upgrade-all
- Aggressively updates package sources and bypasses coordinated lock-file updates.
- Avoid for routine flake-based host rebuilds.

nix-cache and remote builder fit

With nix-cache acting as a binary cache and remote builder, lock-file updates become safer and more reproducible:

CI verifies host evaluations against the updated lock file.
Builds can be performed once on the remote builder.
Built artifacts can be served via nix-cache to other hosts, reducing rebuild time and drift.

Token and secret handling

Do not commit access tokens into flake.nix, flake.lock, or any other tracked file.

If private source access is needed:

configure tokens locally in ~/.config/nix/nix.conf or equivalent machine-local config, or
provide tokens through CI secrets/environment variables.

GitHub Actions setup notes

Ensure GITHUB_TOKEN has permission to create branches and pull requests (workflow sets contents: write and pull-requests: write).
The update workflow uses peter-evans/create-pull-request with branch chore/update-flake-lock.
The evaluation workflow runs on pull requests, pushes to main, and manual dispatch.

Gitea Actions runner setup notes

Ensure the runner image includes Git and can execute the Nix installer action.
For direct push mode, grant workflow push permission to the repository.
The workflow sets commit identity to:
- user.name = gitea-actions
- user.email = gitea-actions@nix-cache.local
Commits are only created when flake.lock actually changes.

3.8 KiB Raw Permalink Blame History