Publish auto-update package and NixOS module as a standalone flake

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

nimmo/nixos-config#61

nimmo commented

2026-07-16 13:52:22 +01:00

Owner

Context

After the updater has a stable package/module boundary inside this repository, it may be valuable to publish it as a standalone Forgejo repository and flake. That would isolate its release cycle, make the implementation independently testable, and allow other NixOS configurations to consume it without copying scripts.

This work depends on #60. It must not begin until the in-repository extraction has been deployed and proven through a genuine update plus a no-op follow-up.

Scope

Create a dedicated Forgejo repository for the updater.
Export:
- the updater package and both commands
- a NixOS module
- package checks and hermetic regression tests
- formatter and development tooling where useful
Define a stable module API for host policy, repository location/owner, scheduling, switch execution, and notification integration.
Keep secrets external: accept file paths or module-provided values without owning this repository's SOPS layout.
Document runtime-state ownership, locking, failure stamps, detached helper units, recovery, and rollback.
Add standalone Forgejo CI for linting, evaluation, package builds, and regression tests.
Add the external flake as a pinned input to nixos-config and migrate the local module configuration.
Establish an update/release policy so automated flake updates cannot silently introduce incompatible updater behaviour.
Retain a simple rollback path to the last in-repository implementation during the initial adoption window.

Completion criteria

#60 is closed with live deployment evidence.
The standalone repository builds and tests without access to nixos-config secrets or host files.
Package and NixOS module outputs have documented interfaces.
CI blocks releases that fail lint, evaluation, or state-machine regressions.
nixos-config consumes an explicitly pinned revision.
Existing command names, runtime paths, service/timer names, hold behaviour, and notifications remain compatible or have a documented migration.
Electra, Vega, and Lyra evaluate and deploy using the external input.
A genuine update and immediate no-op follow-up succeed on the external package.
Rollback to the in-repository package has been tested or documented.
Repository ownership, maintenance expectations, and release/versioning policy are documented.

Dependency

Blocked by #60.

## Context After the updater has a stable package/module boundary inside this repository, it may be valuable to publish it as a standalone Forgejo repository and flake. That would isolate its release cycle, make the implementation independently testable, and allow other NixOS configurations to consume it without copying scripts. This work depends on #60. It must not begin until the in-repository extraction has been deployed and proven through a genuine update plus a no-op follow-up. ## Scope - Create a dedicated Forgejo repository for the updater. - Export: - the updater package and both commands - a NixOS module - package checks and hermetic regression tests - formatter and development tooling where useful - Define a stable module API for host policy, repository location/owner, scheduling, switch execution, and notification integration. - Keep secrets external: accept file paths or module-provided values without owning this repository's SOPS layout. - Document runtime-state ownership, locking, failure stamps, detached helper units, recovery, and rollback. - Add standalone Forgejo CI for linting, evaluation, package builds, and regression tests. - Add the external flake as a pinned input to `nixos-config` and migrate the local module configuration. - Establish an update/release policy so automated flake updates cannot silently introduce incompatible updater behaviour. - Retain a simple rollback path to the last in-repository implementation during the initial adoption window. ## Completion criteria - [ ] #60 is closed with live deployment evidence. - [ ] The standalone repository builds and tests without access to `nixos-config` secrets or host files. - [ ] Package and NixOS module outputs have documented interfaces. - [ ] CI blocks releases that fail lint, evaluation, or state-machine regressions. - [ ] `nixos-config` consumes an explicitly pinned revision. - [ ] Existing command names, runtime paths, service/timer names, hold behaviour, and notifications remain compatible or have a documented migration. - [ ] Electra, Vega, and Lyra evaluate and deploy using the external input. - [ ] A genuine update and immediate no-op follow-up succeed on the external package. - [ ] Rollback to the in-repository package has been tested or documented. - [ ] Repository ownership, maintenance expectations, and release/versioning policy are documented. ## Dependency Blocked by #60.

nimmo added this to the Automated Update Reliability Review milestone

nimmo added the

host:fleet

project:auto-update-reliability

service:auto-update

phase:packaging

labels

nimmo referenced this issue

2026-07-16 13:52:32 +01:00

Extract auto-update implementation into an in-repository package and thin module #60

nimmo closed this issue

2026-07-20 15:24:54 +01:00