Expose `repo: Option<String>` on `ServiceSpec` so consumers can resolve service → source repo #120

New issue

Open

opened 2026-05-21 18:21:24 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-21 18:21:24 +00:00

Owner

Background

We're building hero_cockpit#1 — a per-user control surface that includes a one-click "Upgrade" button per service. The implementation in s138 shells out to lab build <repo> --download --install and then calls hero_proc service.restart.

The problem

To build the lab build argv, the cockpit needs to know which Forgejo repo owns each service binary. Today hero_proc_sdk's ServiceConfig / ServiceSpec does not expose that information — we know name, actions, sockets, tags, etc., but not the source repo path.

We worked around this by hard-coding a static service_name → repo_name map at crates/hero_cockpit_server/src/repos.rs (26 services across our demo set). This duplicates knowledge that hero_proc already implicitly has via its service.toml ingest path, and it must be maintained in lockstep with the demo service set.

Proposed change

Add an optional repo field on ServiceSpec:

pub struct ServiceSpec {
    // ... existing fields ...
    pub repo: Option<String>,  // NEW
}

Populated from a corresponding optional repo = "<owner>/<name>" top-level key in service.toml. None is fine for legacy services; cockpit's static map can be the fallback path.

Acceptance criteria

service.toml schema documents repo as optional top-level string (<owner>/<name> or just <name>).
ServiceSpec.repo is wired through service.list_full's response so SDK consumers can read it.
Backward-compatible: existing service.toml files without a repo key still parse and load.

Out of scope

Migrating existing 35-set service.tomls to populate the field (separate sweep).
Codegen or templating around the field.

Cross-link

Static map workaround landed at hero_cockpit 8ecce62 (s138 — A6 upgrade flow).
Once this lands, that map collapses to a fallback for ServiceSpec.repo.is_none() cases.

## Background We're building [hero_cockpit#1](https://forge.ourworld.tf/lhumina_code/hero_cockpit/issues/1) — a per-user control surface that includes a one-click "Upgrade" button per service. The implementation in s138 shells out to `lab build <repo> --download --install` and then calls `hero_proc service.restart`. ## The problem To build the `lab build` argv, the cockpit needs to know which Forgejo repo owns each service binary. Today `hero_proc_sdk`'s `ServiceConfig` / `ServiceSpec` does not expose that information — we know `name`, `actions`, `sockets`, `tags`, etc., but not the source repo path. We worked around this by hard-coding a static `service_name → repo_name` map at `crates/hero_cockpit_server/src/repos.rs` (26 services across our demo set). This duplicates knowledge that hero_proc already implicitly has via its `service.toml` ingest path, and it must be maintained in lockstep with the demo service set. ## Proposed change Add an optional `repo` field on `ServiceSpec`: ```rust pub struct ServiceSpec { // ... existing fields ... pub repo: Option<String>, // NEW } ``` Populated from a corresponding optional `repo = "<owner>/<name>"` top-level key in `service.toml`. `None` is fine for legacy services; cockpit's static map can be the fallback path. ## Acceptance criteria - `service.toml` schema documents `repo` as optional top-level string (`<owner>/<name>` or just `<name>`). - `ServiceSpec.repo` is wired through `service.list_full`'s response so SDK consumers can read it. - Backward-compatible: existing service.toml files without a `repo` key still parse and load. ## Out of scope - Migrating existing 35-set service.tomls to populate the field (separate sweep). - Codegen or templating around the field. ## Cross-link - Static map workaround landed at hero_cockpit [`8ecce62`](https://forge.ourworld.tf/lhumina_code/hero_cockpit/commit/8ecce62) (s138 — A6 upgrade flow). - Once this lands, that map collapses to a fallback for `ServiceSpec.repo.is_none()` cases.