Let a dev machine opt out of Forge access #10

Merged

vnprc merged 3 commits from agent/microvm-test-machine into master

2026-07-30 22:49:03 +01:00

allod-agent commented

2026-07-30 22:39:23 +01:00

Member

A dev machine that never pushes code no longer has to carry a Forge token. Today every machine in devVMs is unconditionally given forgeTokenFile = secrets/forgejo-https-token-<name>.age, so simply naming a machine there makes its configuration fail to evaluate until someone mints a token for it. That is the wrong default for a throwaway machine, and it turns "add a disposable test VM" into a task that cannot start without a human minting credentials.

Setting forgeAccess = false on a devVMs entry now yields a null token file, which the archetype already handles — the token module is wrapped in lib.optionalAttrs (httpsTokenFile != null), so nothing else changes. Machines that say nothing keep today's behaviour.

This lands the mechanism only. No example machine uses it here, because the machine that needs it is a real one and belongs in the deployment's own data, not in this template.

Risk

R1. One conditional in an identity derivation, with the existing default preserved for every machine that does not opt out. Rollback is a revert.

Validation

nix flake check passes. The mechanism was exercised end to end before being separated out: a throwaway dev machine with forgeAccess = false was added to a scratch copy of this repo plus matching inventory and profile entries, and the composition root evaluated it to a complete system derivation — which it could not do beforehand, failing on the missing token file. That scratch machine was then removed from this branch, leaving only the conditional.

A dev machine that never pushes code no longer has to carry a Forge token. Today every machine in `devVMs` is unconditionally given `forgeTokenFile = secrets/forgejo-https-token-<name>.age`, so simply naming a machine there makes its configuration fail to evaluate until someone mints a token for it. That is the wrong default for a throwaway machine, and it turns "add a disposable test VM" into a task that cannot start without a human minting credentials. Setting `forgeAccess = false` on a `devVMs` entry now yields a null token file, which the archetype already handles — the token module is wrapped in `lib.optionalAttrs (httpsTokenFile != null)`, so nothing else changes. Machines that say nothing keep today's behaviour. This lands the mechanism only. No example machine uses it here, because the machine that needs it is a real one and belongs in the deployment's own data, not in this template. ## Risk R1. One conditional in an identity derivation, with the existing default preserved for every machine that does not opt out. Rollback is a revert. ## Validation `nix flake check` passes. The mechanism was exercised end to end before being separated out: a throwaway dev machine with `forgeAccess = false` was added to a scratch copy of this repo plus matching inventory and profile entries, and the composition root evaluated it to a complete system derivation — which it could not do beforehand, failing on the missing token file. That scratch machine was then removed from this branch, leaving only the conditional.

allod-agent added 3 commits

2026-07-30 22:39:23 +01:00