Skip to content

Operating pipelines

This page describes the operator surface as the web UI presents it. Read What's live vs. demo at the foot before treating any of it as something that reaches a Forge — the CI/CD reads can be live, the gate and run actions are not.

Deploy gates & approvals

A job that targets an environment with a manual gate becomes a manual-approval gate: it parks at waiting-approval until someone approves it, rather than deploying automatically. In the SEED, the Release/deploy job to production is exactly this — a gate that pauses the run before rollout.

You act on a parked gate from the gate banner in the run detail (or from the review page's pipeline rail). Approve deploy clears the gate and lets the deploy proceed; Reject fails the deploy job and blocks its dependents (fail-closed).

Approving a production deploy requires a WebAuthn step-up — a security re-authentication. Both the approve and reject actions on a gate are marked as sensitive, so each routes through the shell's WebAuthn step-up modal before it can fire, and each is guarded by an explicit confirmation:

  • Approve → "Approve deploy to production?" — clears the manual gate and triggers an irreversible rollout of this build.
  • Reject → "Reject the production gate?" — the deploy job fails and its dependents are blocked (fail-closed).

The land gate (fail-closed)

A required deploy/approval gate doesn't just pause the pipeline — it blocks the proposal from landing until it is positively cleared. This is deliberately fail-closed: the land gate tests whether the required node is not cleared (i.e. its state is anything other than success or skipped) rather than enumerating "bad" states. The practical consequence:

  • Approving the gate (→ success) is the only thing that opens landing.
  • Cancelling the run (→ cancelled), re-running the gate (→ pending/running/waiting-approval), or a rejected/failed/blocked gate all keep landing closed.

When a required gate blocks landing, the proposal's Land control is disabled and the reason is surfaced, e.g. "Deploy gate awaiting approval — approve the production gate to continue." or, for a failed required check, "Required check … re-run and pass it before landing." The land action re-checks this at the moment you click, so a stale button can never sneak a land through. (Landing itself lives in the proposal/review flow — see that section.)

Secrets

CI/CD secrets are configured as write-only references, never plaintext. Each secret is a name plus a binding/KV reference (for example REGISTRY_TOKEN → kv://acme/registry-token); the actual value is never stored in or shown by the UI. Adding a secret requires both a name and a reference. At run time, any secret that appears in a log is masked as *** — see the Job detail logs.

Compute metering

The run header shows compute as cpu-min (rounded from CPU-milliseconds), and the Insights tab's Reported compute disclosure aggregates the repo's usage across three dimensions:

  • Job invocations,
  • CPU minutes (from CPU-milliseconds), and
  • GiB-seconds (memory · time).

In the SEED a run carries { cpu_ms, gib_seconds, invocations } and Insights rolls these up. A live read carries no run-level metering at all — neither the run index rows nor a run's own record has the field, and nothing aggregates the per-job figures — so on a connected repository the header prints no cpu-min and every total here is an em dash. That is the honest rendering, not a fault: each total appears only when every loaded run reports the measurement, so a partly-metered window shows a dash rather than a sum that silently omits runs. The panel labels them usage measurements, not billing estimates.

What's live vs. demo

To restate plainly, the two halves differ:

  • Reads can be live. Connected over the Cloud plane, the run list, a run's nodes, its jobs' execution records, the workflows, and the environments and their deployment history are fetched and overlaid onto the derived store. Disconnected — the sample workspace — the same views render the SEED. While a read is in flight the dashboard renders a loading skeleton; if it fails, the section shows an error state with a working Retry rather than putting sample rows back under a heading you were told is live.
  • The pipeline actions are demo. Approve, reject, re-run and cancel mutate the in-memory run and reach no Forge, connected or not. A native Forge serves POST /proposals/:id/pipeline/{approve,reject} and the collaboration client declares both, but nothing calls them; the Cloud plane serving the live reads exposes no gate write at all. So a gate you clear here is a walkthrough. The same holds for the CI settings above: environments, approver rosters and secret references are edited in the demo store.

Two things that read as behaviour rather than data are worth separating out. The land-gate rule described above is genuinely the fail-closed one — it tests "not cleared" rather than enumerating bad states, so cancelling or re-running a required gate can never open Land. And a job with an environment: is not actually parked for approval by a Forge today: the scheduler admits every node Automatic (see the notice on the CI/CD overview), so the manual gate you drive here is the model's design, shown against demo data.

Grounded in: packages/tovio-web-ui/src/repo/pipelines.js (renderers), packages/tovio-web-ui/src/repo/data.js (SEED, projections, runFromWire, land-gate logic, and applyRepoAction), and packages/tovio-web-ui/src/shell/scopes/repo.js (the live reads and the write tables).

Last reviewed September 9, 2026

Suggest an improvement to this page Not for security reports — see disclosure