10 – Add Forgejo CI Build Validation #241

New issue

Open

opened 2026-09-19 20:37:12 +01:00 by nimmo · 0 comments

nimmo commented

2026-09-19 20:37:12 +01:00

Owner

Goal

Extend existing Forgejo CI validation for nixos-config without granting CI any deployment authority or allowing it to starve interactive Nova builds.

Dependencies

Follow #232/#234; coordinate with #238 for credential boundaries.

Context

.forgejo/workflows/attic-cache.yml already runs evaluation/checks on Nova, performs pull-request validation, and builds/pushes accepted main closures to Attic. This issue must extend and isolate that established workflow rather than introduce a parallel, contradictory CI path.

Requirements

Define useful PR validation (flake checks, affected-host evaluation, and builds where justified) with clear diagnostics.
Keep untrusted PR validation separate from Forgejo publication, Attic push, remediation publication, and all target activation credentials.
If CI uses remote-builder capacity, define concurrency, queueing, cache, and resource reservations so CI does not block interactive deployment or existing scheduled work.
A successful CI build is evidence of buildability only; it never authorises test, boot, switch, or target SSH access.

Validation

Demonstrate a valid change passes and an invalid change fails with useful diagnostics. Verify the relevant CI job has no deployment credentials or target activation path, and confirm existing Attic/auto-update CI behaviour remains intact.

## Goal Extend existing Forgejo CI validation for `nixos-config` without granting CI any deployment authority or allowing it to starve interactive Nova builds. ## Dependencies Follow #232/#234; coordinate with #238 for credential boundaries. ## Context `.forgejo/workflows/attic-cache.yml` already runs evaluation/checks on Nova, performs pull-request validation, and builds/pushes accepted `main` closures to Attic. This issue must extend and isolate that established workflow rather than introduce a parallel, contradictory CI path. ## Requirements - Define useful PR validation (flake checks, affected-host evaluation, and builds where justified) with clear diagnostics. - Keep untrusted PR validation separate from Forgejo publication, Attic push, remediation publication, and all target activation credentials. - If CI uses remote-builder capacity, define concurrency, queueing, cache, and resource reservations so CI does not block interactive deployment or existing scheduled work. - A successful CI build is evidence of buildability only; it never authorises `test`, `boot`, `switch`, or target SSH access. ## Validation Demonstrate a valid change passes and an invalid change fails with useful diagnostics. Verify the relevant CI job has no deployment credentials or target activation path, and confirm existing Attic/auto-update CI behaviour remains intact.

nimmo added this to the NixOS Build & Deployment Pipeline milestone

2026-09-19 20:37:12 +01:00

nimmo added the

host:fleet

host:nova

phase:validation

project:nixos-build-deployment-pipeline

service:nix

labels

2026-09-19 21:02:42 +01:00

~~nimmo referenced this issue 2026-09-23 18:44:07 +01:00~~

07 – Harden Build and Deployment Trust Boundaries #238