## Summary <:robot:> Release loop of [gitlab-org/lab-bench&2] (DM-3.5). See the epic for the shared root cause, the cross-team coordination, and the interim reality; this issue owns the release-loop implementation. `bench build --release` produces one OCI image and one Fairway manifest per assembly, written to `.runway/<assembly>/fairway.yaml`. The release-platform CI component ([`release-platform.yml`](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/blob/v4.39.0/release-platform.yml#L52) v4.39.0) reads exactly **one manifest per repository**, at `<runway_dir>/fairway.yaml` (`runway_dir` defaults to `.runway`, so `.runway/fairway.yaml`), and a required job ([`fairway-manifest-path-check`](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/blob/v4.39.0/release-platform.yml#L90)) fails the pipeline until that single path resolves. So a bench with one assembly deploys today while a bench with 2+ produces artifacts the platform cannot deploy. The decision (from the [2026-08-13 LabBench weekly](https://docs.google.com/document/d/1jtLUUlyVsihK0IlITL29Oj-r8Cwo-gBDZEGT5PS-LH4/edit?tab=t.0#heading=h.z5f5mfp31p0m)) is to keep `bench` emitting one manifest per assembly and work with the release team to teach the component to consume more than one. That component change is tracked in the epic and in [delivery#22107](https://gitlab.com/gitlab-com/gl-infra/delivery/-/work_items/22107#note_3683669037). > Note: the per-assembly manifest generator lands with > [!73](https://gitlab.com/gitlab-org/lab-bench/bench/-/merge_requests/73) > (issue [#55](https://gitlab.com/gitlab-org/lab-bench/bench/-/issues/55)); code > links below point at that branch where the file is not yet on `main`. <details> <summary>Why the constraint is the CI component, not Fairway or bench</summary> The Fairway schema and generator already fit one-manifest-per-assembly. A `Manifest` carries one `ServiceSpec`, so N assemblies are N individually valid manifests: no proto change, no `repeated ServiceSpec`. bench renders the image and manifest from the same values, so they cannot name different repositories or ports: [`assembly_fairway_path`](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3b442f274e2a92f5593a799d68a41ad4acd11878/cli/src/build/deploy.rs#L30) and [`write_fairway`](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3b442f274e2a92f5593a799d68a41ad4acd11878/cli/src/build/deploy.rs#L90). The constraint lives one layer up, in the release-platform CI component: - It derives a single manifest at `<runway_dir>/fairway.yaml` from one `runway_dir` input. - A required check fails the pipeline until the manifest resolves at that path, and the component derives the path from `runway_dir`. - It reads one `.metadata.name` from that one manifest. The fairway path is derived from `runway_dir` alone. There is no way to point the component at N manifests, so multi-assembly production is blocked upstream of bench, not in it. Source: [`release-platform.yml` v4.39.0](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/blob/v4.39.0/release-platform.yml). </details> ## Scope ### In scope **Add a guard so a multi-assembly bench fails early and honestly.** <details> <summary>Today it fails on the CI path-check with no actionable message</summary> `bench build` and `bench scaffold` both loop over every assembly with no count check; the only invariant enforced is single-runtime ([`bench_single_runtime`](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3bb04252bfa47d5cd4fa4ae93f2984f535696674/cli/src/cmd/scaffold.rs#L291)). The build loop is [here](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3bb04252bfa47d5cd4fa4ae93f2984f535696674/cli/src/main.rs#L680) and the scaffold assembly collection [here](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3bb04252bfa47d5cd4fa4ae93f2984f535696674/cli/src/cmd/scaffold.rs#L455). A two-assembly bench writes two nested manifests and the pipeline fails on the required path-check with nothing pointing at the real cause. Until the component change lands, warn `bench build --release` (and scaffold) on a bench with more than one assembly, with a message naming the reason: the release-platform component deploys one manifest per repo; split into single-assembly benches for now. </details> **Wire N Fairway manifests through CI once the component change lands.** bench already emits per-assembly manifests; this is the CI-side fan-out that consumes them, using whichever component shape the epic settles with the release team. The `caproni.yaml`-block authoring mechanism (template-loop vs. post-scaffold-append) is a shared decision made here and reused by [#59]. ### Out of scope - The Caproni local-rig fan-out. That is [#59]. - Runway's N-deployments-off-one-chart support (the iam-auth HTTP+gRPC case). That is N deployments of one image; bench's case is N images, which is the component gap above. ## References - Epic: [gitlab-org/lab-bench&2] (DM-3.5) - [2026-08-13 LabBench weekly](https://docs.google.com/document/d/1jtLUUlyVsihK0IlITL29Oj-r8Cwo-gBDZEGT5PS-LH4/edit?tab=t.0#heading=h.z5f5mfp31p0m) - release-platform component: https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/blob/v4.39.0/release-platform.yml - bench manifest generator: !73 - [LB-D20 scaffold layout](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3bb04252bfa47d5cd4fa4ae93f2984f535696674/docs/decisions/LB-D20-scaffold-layout.md), [LB-D21 bench build generates deployment files](https://gitlab.com/gitlab-org/lab-bench/bench/-/blob/3bb04252bfa47d5cd4fa4ae93f2984f535696674/docs/decisions/LB-D21-template-split.md) - https://gitlab.com/gitlab-org/lab-bench/bench/-/merge_requests/46+ (GATE/IAM multi-service bench.yaml; mkaeppler/mjhoad "n charts per repo") - https://gitlab.com/gitlab-org/lab-bench/bench/-/issues/55+ (spec.image reconciliation + Runway nested-path confirmation) [gitlab-org/lab-bench&2]: https://gitlab.com/groups/gitlab-org/lab-bench/-/work_items/2 [#59]: https://gitlab.com/gitlab-org/lab-bench/bench/-/work_items/59