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

beatzaplentyandClaude Sonnet 5 c05e3a3821

Check NixOS configurations / eval-hosts (push) Failing after 12m2s

Details

Refactor flake targets into platform x build-type matrix

Generates all nixosConfigurations from mkTarget(platform, buildType,
hostPath) instead of hand-written per-host blocks, so adding a new
platform or build type is a one-line addition. Per-machine identity
(hostname, hostId, secrets, stateVersion) moves into hosts/<name>/host.nix;
platform-specific config (hardware, boot, networking) into
modules/platforms/*.nix; build-type config (minimal/server/docker/gui/
nix-cache/pxe-boot) into modules/build-types/*.nix.

Old flat targets (nixos, docker, server, nix-cache, nix-minimal, pxe-boot)
are replaced by the 17-target <platform>-<buildtype> matrix; each new
target was verified to evaluate before its old counterpart was removed.
CI workflows and docs/aliases now discover hosts dynamically via
nixosConfigurations attrNames and /etc/flake-target instead of hardcoded
lists, so they can't drift from flake.nix again.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-07-19 12:03:33 +10:00

3.5 KiB

Raw 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 evaluates every configured host before merge, listed dynamically via nix eval --json .#nixosConfigurations --apply builtins.attrNames rather than hand-enumerated, so it 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.5 KiB Raw Blame History