allod forge up: start the forge VM if needed and print its URL #85

New issue

Open

opened 2026-10-08 05:19:37 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-08 05:19:37 +01:00

Reaching the forge VM means knowing its address and whether it is running. allod forge up starts it if it is not, says nothing if it is, waits until it answers, and prints the URL.

Primary goals:

One command, whatever the state — starts the domain if it is not running, no-ops if it is, and in both cases exits having confirmed the forge answers rather than merely that the domain is defined.
Waits for the service, not the domain — a started domain is not a served forge; the command returns once the HTTP port responds, so what it prints is known good.
Prints the URL — the address comes from the registry, so it is correct on every deployment without being typed anywhere.
Host-only and honest about it — starting a domain needs local virsh, so the command refuses with a clear message anywhere else rather than failing obscurely.

Current state and specifics

allod dispatches any namespace it does not list to allod-<namespace> on PATH, so this lands as allod-forge and is invoked as allod forge up. The precedent for a per-machine operator command is the private allod bitcoin status|start|stop, a module in a deployment's own profiles; this one is public because the forge is part of allod/strategy#65 and every template operator should get it.

Worth knowing from that precedent: start and stop there drive the libvirt domain with local virsh and so only run on the hypervisor hosting the guest, and status waits on the guest's own service rather than the domain, because a machine mid-start answers nothing. Both apply here.

A name collision is accepted deliberately: forge is already a binary on these machines — the Forgejo CLI for issues and pull requests — so allod forge up sits beside forge pr create. The owner accepted this as a namespaced nuisance rather than renaming (decision, 2026-10-08).

Scope

In: the command, its shell test alongside the others in tests/, and the README. Out: a down or status subcommand unless they fall out for free; reaching the forge by name rather than address, which is a coupled change across the profile's domain and Caddy's site address and is deliberately deferred; and anything that creates or changes forge content, which is forge-sync.

Part of allod/strategy#65

Reaching the forge VM means knowing its address and whether it is running. `allod forge up` starts it if it is not, says nothing if it is, waits until it answers, and prints the URL. Primary goals: - **One command, whatever the state** — starts the domain if it is not running, no-ops if it is, and in both cases exits having confirmed the forge answers rather than merely that the domain is defined. - **Waits for the service, not the domain** — a started domain is not a served forge; the command returns once the HTTP port responds, so what it prints is known good. - **Prints the URL** — the address comes from the registry, so it is correct on every deployment without being typed anywhere. - **Host-only and honest about it** — starting a domain needs local virsh, so the command refuses with a clear message anywhere else rather than failing obscurely. ### Current state and specifics `allod` dispatches any namespace it does not list to `allod-<namespace>` on PATH, so this lands as `allod-forge` and is invoked as `allod forge up`. The precedent for a per-machine operator command is the private `allod bitcoin status|start|stop`, a module in a deployment's own profiles; this one is public because the forge is part of allod/strategy#65 and every template operator should get it. Worth knowing from that precedent: `start` and `stop` there drive the libvirt domain with local virsh and so only run on the hypervisor hosting the guest, and `status` waits on the guest's own service rather than the domain, because a machine mid-start answers nothing. Both apply here. A name collision is accepted deliberately: `forge` is already a binary on these machines — the Forgejo CLI for issues and pull requests — so `allod forge up` sits beside `forge pr create`. The owner accepted this as a namespaced nuisance rather than renaming (decision, 2026-10-08). ### Scope In: the command, its shell test alongside the others in `tests/`, and the README. Out: a `down` or `status` subcommand unless they fall out for free; reaching the forge by name rather than address, which is a coupled change across the profile's `domain` and Caddy's site address and is deliberately deferred; and anything that creates or changes forge content, which is `forge-sync`. Part of allod/strategy#65

vnprc-agent referenced this issue from allod/strategy

2026-10-09 05:14:20 +01:00

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

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 from allod/strategy

2026-10-09 23:10:21 +01:00

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