allod secret rotate: resolve the deploy checkout through the inventory registry instead of printing ~/work/allod/deploy #211

New issue

Closed

opened 2026-09-13 00:31:43 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-09-13 00:31:43 +01:00

Contributor

allod secret rotate prints its deploy-flake steps with a hardcoded ~/work/allod/deploy (cmd/allod/secret_rotate.go, the printRebuildCommand line and the "Update the deploy flake lock" step), so on a deployment whose composition root lives elsewhere the operator is told to bump the wrong lock and rebuild from the wrong flake. The secrets checkout on the same command is already resolved through the inventory's repository registry with INVENTORY honoured; the deploy checkout should be resolved the same way.

Primary goals:

Resolve, don't spell — the deploy checkout comes from the repository registry's deploy entry (~/work/<checkout>), falling back to allod/deploy only when the registry does not name one, exactly as resolveSecretsCheckout does for secrets.
One printed truth — both places that print the path read one resolved value, and a test pins that a registry naming a different checkout changes the printed steps.

Current state and specifics

Seen on a first --dry-run after the value-template migration: every other line (group, targets, verify command, refresh-local-auth step) was correct and read from the registry; only the two deploy lines named the template path. The operator's real composition root was one directory up.

Scope

In: the two printed paths and a test. Out: the rest of the printed step sequence, which is right.

Refs allod/secrets#23, allod/nexus#52.

`allod secret rotate` prints its deploy-flake steps with a hardcoded `~/work/allod/deploy` (`cmd/allod/secret_rotate.go`, the `printRebuildCommand` line and the "Update the deploy flake lock" step), so on a deployment whose composition root lives elsewhere the operator is told to bump the wrong lock and rebuild from the wrong flake. The secrets checkout on the same command is already resolved through the inventory's repository registry with `INVENTORY` honoured; the deploy checkout should be resolved the same way. Primary goals: - **Resolve, don't spell** — the deploy checkout comes from the repository registry's `deploy` entry (`~/work/<checkout>`), falling back to `allod/deploy` only when the registry does not name one, exactly as `resolveSecretsCheckout` does for secrets. - **One printed truth** — both places that print the path read one resolved value, and a test pins that a registry naming a different checkout changes the printed steps. ### Current state and specifics Seen on a first `--dry-run` after the value-template migration: every other line (group, targets, verify command, `refresh-local-auth` step) was correct and read from the registry; only the two deploy lines named the template path. The operator's real composition root was one directory up. ### Scope In: the two printed paths and a test. Out: the rest of the printed step sequence, which is right. Refs allod/secrets#23, allod/nexus#52.

vnprc-agent referenced this issue from a commit

2026-09-13 00:32:00 +01:00

Name allod/tools#211