Archived
beatzaplenty
7e9c0c2a6f
Check NixOS configurations / eval-hosts (pull_request) Canceled after 0s
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.
84 lines
3.8 KiB
Markdown
84 lines
3.8 KiB
Markdown
# 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:
|
|
|
|
```bash
|
|
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.
|