A `service.forge` profile: Forgejo in fresh mode over plain http #12

New issue

Closed

opened 2026-10-07 05:08:04 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-07 05:08:04 +01:00

The example profiles gain a service.forge definition: Forgejo in fresh-install mode over plain http, which is what a forge on a private network needs. This is the behaviour half of the template's forge machine.

Primary goals:

A service.forge definition — composes the framework's Forgejo module through the allodModules seam and sets mode = "fresh" and tls = false, the two switches the module added for exactly this case.
Clone and administrative SSH on separate ports — sshPort = 2222 for the clone daemon and adminSshPort = 22, so the hypervisor's provisioning and allod scripts reach the machine on the port they already use, and clone URLs carry the port the dev VM's identity already renders.
The ports the service listens on, and nothing else — the definition opens what Forgejo needs; the archetype's default egress keeps the guest to its own LAN, which is all a forge on the guest network requires.
Evaluation is the witness — the profile-definition contract check passes, and the machine evaluates through the deploy template once the inventory and secrets halves land.

Current state and specifics

profileDefinitions is a literal attrset keyed by archetype; service becomes its fourth key alongside dev, privacy and hypervisor. Archetype-name validity is asserted by the framework, not here.

This repo declares only nixpkgs as an input and must keep it that way, so the Forgejo module arrives as allodModules.forgejo in the module's arguments rather than as a flake input. That seam is the subject of the companion allod/archetypes issue and must land first.

Two facts measured while the module was built: admin is a reserved Forgejo username, so the human account the bootstrap later creates is operator; and the module pins services.forgejo.package to the channel's current release with mkDefault, so this definition does not need to name a package.

Scope

In: the service.forge definition and the README's description of it. Out: the machine facts (allod/inventory), the identity and host key (allod/secrets), the allodModules seam (allod/archetypes), and the accounts, org, repositories and token that forge-bootstrap creates (allod/nexus) — a profile describes the machine, not its contents.

Part of allod/strategy#65

The example profiles gain a `service.forge` definition: Forgejo in fresh-install mode over plain http, which is what a forge on a private network needs. This is the behaviour half of the template's `forge` machine. Primary goals: - **A `service.forge` definition** — composes the framework's Forgejo module through the `allodModules` seam and sets `mode = "fresh"` and `tls = false`, the two switches the module added for exactly this case. - **Clone and administrative SSH on separate ports** — `sshPort = 2222` for the clone daemon and `adminSshPort = 22`, so the hypervisor's provisioning and `allod` scripts reach the machine on the port they already use, and clone URLs carry the port the dev VM's identity already renders. - **The ports the service listens on, and nothing else** — the definition opens what Forgejo needs; the archetype's default egress keeps the guest to its own LAN, which is all a forge on the guest network requires. - **Evaluation is the witness** — the profile-definition contract check passes, and the machine evaluates through the deploy template once the inventory and secrets halves land. ### Current state and specifics `profileDefinitions` is a literal attrset keyed by archetype; `service` becomes its fourth key alongside `dev`, `privacy` and `hypervisor`. Archetype-name validity is asserted by the framework, not here. This repo declares only `nixpkgs` as an input and must keep it that way, so the Forgejo module arrives as `allodModules.forgejo` in the module's arguments rather than as a flake input. That seam is the subject of the companion `allod/archetypes` issue and must land first. Two facts measured while the module was built: `admin` is a reserved Forgejo username, so the human account the bootstrap later creates is `operator`; and the module pins `services.forgejo.package` to the channel's current release with `mkDefault`, so this definition does not need to name a package. ### Scope In: the `service.forge` definition and the README's description of it. Out: the machine facts (`allod/inventory`), the identity and host key (`allod/secrets`), the `allodModules` seam (`allod/archetypes`), and the accounts, org, repositories and token that `forge-bootstrap` creates (`allod/nexus`) — a profile describes the machine, not its contents. Part of allod/strategy#65

vnprc-agent referenced this issue from allod/strategy

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

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