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

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 second run of getting-started.sh, as getting-started.sh --forge, points the deployment's dev VM at its own forge VM: the agent in the VM then opens pull requests and issues on a forge the operator owns, and a push to master is refused by that forge, with no hosted forge and no account anywhere else.

Primary goals:

One flag, after forge-sync — the operator provisions the forge machine, runs forge-sync forge on the host, commits what it prints, and runs bash getting-started.sh --forge; the script refuses, naming the step, when forge-sync has not run (no secrets/allod-dev-forge-key.age, no secrets/agent-pr-token.age, or forgeAccess still false).
Identity points at the VM — forgeHost becomes the forge machine's address from the inventory, forgePort its clone port, and forgeUrl becomes http://<address> (set, or added after forgePort when the clone predates allod/secrets#44).
Inventory gives the VM its key back — forge_key = "allod_vm" restored and host_provided_repos dropped on allod-dev, scripts/vm-specs.json regenerated, committed.
The re-lock is verified, which also settles allod/deploy#9 — the three data inputs are re-locked with --refresh and the script reads each pinned revision back out of flake.lock and stops with both values if it did not reach the clone's HEAD; the first run's re-lock takes the same function.
Ends by naming the next step — provision-vm --replace allod-dev, with one line saying it replaces the VM, because the guest clone step pulls an existing checkout and a host-provided checkout has no remote to pull from; rebuild-vm would not re-clone.
Rerunnable — a second --forge run finds every edit in place and reports it, like the first run's steps.

Current state and specifics

getting-started.sh step 3 clears forgeAccess, step "Dev VM built from the local clones" sets forge_key = null and declares host_provided_repos, and step 4 re-locks with nix flake update "${DATA_INPUTS[@]}" and trusts the exit status (allod/deploy#9). The forge machine's address is machines.forge.ip in the inventory, already moved onto libvirt's network by the first run; its clone port is the one the forge profile declares (2222). forge-sync (allod/nexus) generates the dev VM's forge key, grants forgeAccess, mints the token, pushes the repositories and prints the secrets commit and re-lock lines; it does not touch inventory or the forge host fields, which is this flag's job. The dev VM renders FORGE_URL from forgeUrl once allod/deploy pins the archetypes revision carrying allod/archetypes#142, so this change's lock bump moves archetypes and allod-secrets to the revisions carrying allod/archetypes#142 and allod/secrets#44.

Validation

The script's edits are exercised on a dev machine against throwaway clones of the public templates under a scratch HOME, with ALLOD_HARDWARE_CONFIG pointed at a fixture and --prepare-only stopping before any build: run 1, then fake forge-sync's outputs in the scratch secrets clone, then --forge --prepare-only, and read back identity, inventory and the lock. The laptop witness is the operator's: as the second run of the script on the public install walk's machine, after provision-vm --replace allod-dev, the VM's FORGE_URL and clone remotes name the forge VM, forge issue create from the VM is read back through the forge's API, and a push to master is refused by the server with the client's hook disabled for that one push.

Scope

In: the --forge flag, the precondition, the identity and inventory edits, the shared verified re-lock, the README section, and the lock bump. Out: forge-sync itself; reaching the forge by name rather than address, deferred by decision; the hypervisor's own clones, which keep their upstream remotes so the operator still pulls template updates from the public forge.

Part of allod/strategy#65

A second run of `getting-started.sh`, as `getting-started.sh --forge`, points the deployment's dev VM at its own forge VM: the agent in the VM then opens pull requests and issues on a forge the operator owns, and a push to master is refused by that forge, with no hosted forge and no account anywhere else. Primary goals: - **One flag, after `forge-sync`** — the operator provisions the `forge` machine, runs `forge-sync forge` on the host, commits what it prints, and runs `bash getting-started.sh --forge`; the script refuses, naming the step, when `forge-sync` has not run (no `secrets/allod-dev-forge-key.age`, no `secrets/agent-pr-token.age`, or `forgeAccess` still false). - **Identity points at the VM** — `forgeHost` becomes the forge machine's address from the inventory, `forgePort` its clone port, and `forgeUrl` becomes `http://<address>` (set, or added after `forgePort` when the clone predates allod/secrets#44). - **Inventory gives the VM its key back** — `forge_key = "allod_vm"` restored and `host_provided_repos` dropped on `allod-dev`, `scripts/vm-specs.json` regenerated, committed. - **The re-lock is verified, which also settles allod/deploy#9** — the three data inputs are re-locked with `--refresh` and the script reads each pinned revision back out of `flake.lock` and stops with both values if it did not reach the clone's HEAD; the first run's re-lock takes the same function. - **Ends by naming the next step** — `provision-vm --replace allod-dev`, with one line saying it replaces the VM, because the guest clone step pulls an existing checkout and a host-provided checkout has no remote to pull from; `rebuild-vm` would not re-clone. - **Rerunnable** — a second `--forge` run finds every edit in place and reports it, like the first run's steps. ### Current state and specifics `getting-started.sh` step 3 clears `forgeAccess`, step "Dev VM built from the local clones" sets `forge_key = null` and declares `host_provided_repos`, and step 4 re-locks with `nix flake update "${DATA_INPUTS[@]}"` and trusts the exit status (allod/deploy#9). The forge machine's address is `machines.forge.ip` in the inventory, already moved onto libvirt's network by the first run; its clone port is the one the `forge` profile declares (2222). `forge-sync` (`allod/nexus`) generates the dev VM's forge key, grants `forgeAccess`, mints the token, pushes the repositories and prints the secrets commit and re-lock lines; it does not touch inventory or the forge host fields, which is this flag's job. The dev VM renders `FORGE_URL` from `forgeUrl` once `allod/deploy` pins the archetypes revision carrying allod/archetypes#142, so this change's lock bump moves `archetypes` and `allod-secrets` to the revisions carrying allod/archetypes#142 and allod/secrets#44. ### Validation The script's edits are exercised on a dev machine against throwaway clones of the public templates under a scratch `HOME`, with `ALLOD_HARDWARE_CONFIG` pointed at a fixture and `--prepare-only` stopping before any build: run 1, then fake `forge-sync`'s outputs in the scratch secrets clone, then `--forge --prepare-only`, and read back identity, inventory and the lock. The laptop witness is the operator's: as the second run of the script on the public install walk's machine, after `provision-vm --replace allod-dev`, the VM's `FORGE_URL` and clone remotes name the forge VM, `forge issue create` from the VM is read back through the forge's API, and a push to master is refused by the server with the client's hook disabled for that one push. ### Scope In: the `--forge` flag, the precondition, the identity and inventory edits, the shared verified re-lock, the README section, and the lock bump. Out: `forge-sync` itself; reaching the forge by name rather than address, deferred by decision; the hypervisor's own clones, which keep their upstream remotes so the operator still pulls template updates from the public forge. Part of allod/strategy#65

vnprc referenced this issue from a commit

2026-10-09 13:01:05 +01:00

getting-started.sh: --forge points the dev VM at its own forge

vnprc referenced this issue from a commit

2026-10-09 13:01:05 +01:00

getting-started.sh: fix-round from cold review of the --forge change

vnprc referenced this issue from a commit

2026-10-09 13:01:05 +01:00

flake.lock: update archetypes, secrets for FORGE_URL and forgeUrl

vnprc-agent referenced this issue from allod/strategy

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

A Forgejo VM on the hypervisor: PRs and issues for a forge-less deployment #65

vnprc-agent referenced this issue

2026-10-09 16:26:54 +01:00

getting-started.sh with no arguments dies on an empty argument from its own re-exec #12

vnprc referenced this issue from a commit

2026-10-09 16:29:44 +01:00

getting-started.sh: re-exec with no arguments passes none

allod-agent added the

landed?

label

2026-10-21 22:27:15 +01:00

allod-agent commented

2026-10-21 23:32:26 +01:00

Member

Landed on master in commit 7432a9e: the --forge second run, with the fix round in f937f60. Verified against the files on master today; closing as completed.

Landed on master in commit 7432a9e: the --forge second run, with the fix round in f937f60. Verified against the files on master today; closing as completed.

allod-agent

2026-10-21 23:32:26 +01:00