Dev VMs render FORGE_URL from identity #142

New issue

Closed

opened 2026-10-09 06:06:47 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-09 06:06:47 +01:00

A dev VM's shell and its forge CLI learn the forge's web address from the VM's identity, so a deployment whose forge is a plain-http VM on the private network gets a working forge issue create with no per-VM configuration.

Primary goals:

FORGE_URL rendered from identity — the dev builder sets environment.sessionVariables.FORGE_URL to the runtime identity's forgeUrl, the same way it renders INVENTORY; not home.sessionVariables, because ssh <vm> <command> sources no login profile.
Older secrets forks need nothing — the builder reads runtimeIdentity.forgeUrl or "https://${runtimeIdentity.forgeHost}", so a secrets input that predates the field (allod/secrets#44) renders today's default and no machine changes its behaviour.
A check proves the rendering — an eval check drives builders.dev with a fixture identity carrying forgeUrl = "http://192.0.2.12" and asserts the rendered variable; a second fixture without the field asserts the https:// default.
README names it — the Builders paragraph lists FORGE_URL beside INVENTORY as a variable the dev home renders from data.

Current state and specifics

nix/builders/dev.nix renders the forge ssh block from runtimeIdentity.forgeHost and forgePort (modules/dev-ssh-forge.nix) and sets environment.sessionVariables.INVENTORY when an inventory checkout is given; it sets no FORGE_URL. The forge CLI (allod/tools, cmd/forge/main.go) reads FORGE_URL and defaults to https://forge.anarch.diy, so on a deployment whose forge is the forge service VM (plain http at the guest's address, allod/profiles hosts/service/forge) every API call from the VM goes to the wrong host while ssh clones work. The end-to-end witness in checks/forge-sync.nix already sets FORGE_URL=http://<forge ip> by hand on its client node, which is the shape this makes automatic.

Scope

In: the one sessionVariables entry in the dev builder, its check, and the README line. Out: the identity field itself (allod/secrets#44); the install script's second run (allod/deploy); privacy and service builders, which run no forge CLI.

Part of allod/strategy#65

A dev VM's shell and its `forge` CLI learn the forge's web address from the VM's identity, so a deployment whose forge is a plain-http VM on the private network gets a working `forge issue create` with no per-VM configuration. Primary goals: - **`FORGE_URL` rendered from identity** — the dev builder sets `environment.sessionVariables.FORGE_URL` to the runtime identity's `forgeUrl`, the same way it renders `INVENTORY`; not `home.sessionVariables`, because `ssh <vm> <command>` sources no login profile. - **Older secrets forks need nothing** — the builder reads `runtimeIdentity.forgeUrl or "https://${runtimeIdentity.forgeHost}"`, so a secrets input that predates the field (allod/secrets#44) renders today's default and no machine changes its behaviour. - **A check proves the rendering** — an eval check drives `builders.dev` with a fixture identity carrying `forgeUrl = "http://192.0.2.12"` and asserts the rendered variable; a second fixture without the field asserts the `https://` default. - **README names it** — the Builders paragraph lists `FORGE_URL` beside `INVENTORY` as a variable the dev home renders from data. ### Current state and specifics `nix/builders/dev.nix` renders the forge ssh block from `runtimeIdentity.forgeHost` and `forgePort` (`modules/dev-ssh-forge.nix`) and sets `environment.sessionVariables.INVENTORY` when an inventory checkout is given; it sets no `FORGE_URL`. The `forge` CLI (`allod/tools`, `cmd/forge/main.go`) reads `FORGE_URL` and defaults to `https://forge.anarch.diy`, so on a deployment whose forge is the `forge` service VM (plain http at the guest's address, `allod/profiles` `hosts/service/forge`) every API call from the VM goes to the wrong host while ssh clones work. The end-to-end witness in `checks/forge-sync.nix` already sets `FORGE_URL=http://<forge ip>` by hand on its client node, which is the shape this makes automatic. ### Scope In: the one `sessionVariables` entry in the dev builder, its check, and the README line. Out: the identity field itself (allod/secrets#44); the install script's second run (allod/deploy); privacy and service builders, which run no forge CLI. Part of allod/strategy#65

vnprc-agent referenced this issue from allod/deploy

2026-10-09 06:06:47 +01:00

getting-started.sh --forge: point the dev VM at the forge VM #11