The CI/CD web UI & operating pipelines¶
TOVIO's pipeline runs, workflows, deployments, and approval gates all surface in one place: the repo's CI/CD section in the TOVIO web UI. This is where you watch a run's job graph advance, approve a production deploy, open a job's masked logs, and read success-rate and compute-usage trends.
Read this first — reads can be live; the pipeline actions are not. Connected to a repository over the Cloud plane, the CI/CD views read for real: the run list, a run's nodes, its jobs' execution records, the workflow list, and the environments/deployments all come off the wire and overlay a freshly-derived store. Disconnected — the sample workspace — the same views render a realistic in-memory SEED that mirrors the backend wire types (
RunStatus,PipelineNode/NodeStatus,NodeState,GateKind,RunPhase), so the two are shaped alike on purpose.What is not wired is the acting half. Approve, reject, re-run and cancel are still reducers over the in-memory store: they make the flows drivable and they never reach a Forge, connected or not. A native Forge does serve
POST /proposals/:id/pipeline/{approve,reject}and the collaboration client declares both, but nothing calls them; the Cloud plane that serves these live reads has no gate-write route at all. Treat a gate you clear here as a walkthrough, not a deploy. See What's live vs. demo at the end of this section.
Where to find it¶
Open a repository in the web UI and select CI/CD from the repo navigation. If CI/CD has been turned off for the repo, the section shows a banner instead:
CI/CD is disabled for this repository. Enable it in Settings › CI/CD.
The dashboard¶
The CI/CD landing view is a dashboard with a segmented sub-nav across four tabs:
| Tab | What it shows |
|---|---|
| Runs | Every pipeline run, filterable and searchable |
| Workflows | The repo's imported workflow files as clickable cards |
| Insights | Success rate, durations, compute usage, most-failing jobs |
| Environments | Per-environment deployment history and protection |
The Environments tab carries a count badge equal to the number of deploy gates currently awaiting approval, so pending approvals are visible from the sub-nav.
Runs¶
The Runs tab opens with four stat tiles — Runs (total), Active, Awaiting approval, and Failing — followed by one control bar and the run list.
The control bar has:
- A search box (
Search runs, commit, actor…) matching against title, lane, run id, commit, commit message, actor, and workflow. - Phase facets: All, Running, Awaiting, Passed, Failed (each with a count).
- Two filter selects: workflow and actor.
Each run is a card you click to open the run detail. A card shows the run's phase pill, the proposal title, and a meta line of coordinates (run_id, commit, lane, trigger, started). Run ids are keyed "<proposal>@<revision>" — one run per (proposal, revision) — for example prop:42@3. On the right the card shows the actor, a jobs progress label like 5/6 jobs · 1 awaiting, and, when the run has any parked gate, a 1 gate awaiting you pill.
Workflows¶
The Workflows tab is a grid of the repo's imported .github/workflows/* files (plus any config-as-code pipelines). Each card shows the workflow name and path, its trigger pills (with a manual pill when manual dispatch is enabled), its jobs (tagged matrix / gate / environment where applicable), the environments it deploys to, and a disabled pill when the workflow is turned off. Click a card to open the workflow detail.
Insights¶
See Insights below.
Environments¶
See Environments & deployments below.
Run detail: the job DAG¶
Opening a run shows a two-tier header, an optional gate banner, and the run's jobs drawn as a real directed graph.
The header carries the phase pill and proposal title, an identity line (actor + reviewed commit + commit message), and a de-emphasized facts line: run_id, jobs_done/jobs_total jobs, trigger, lane, started → finished · duration, attempt number, and metered compute (e.g. 4 cpu-min).
The graph itself is the centerpiece. Jobs are laid out in topological columns by their needs depth, and each needs dependency is drawn as a curved edge from the upstream node to the downstream one — so a fan-out matrix and a downstream gate read as an actual DAG, not a list. Each node is a card colored by its state, with the check name (linking to the job detail), any environment / gate tags, and a foot line showing its duration or status detail.
Node states use this vocabulary (mirroring the backend NodeState):
| State | Meaning |
|---|---|
pending |
Not started (waiting on upstream jobs) |
running |
Executing now |
waiting-approval |
A manual deploy gate, parked for approval |
success |
Passed |
failure |
Failed |
blocked |
A required upstream job failed, so this job can't run (fail-closed) |
cancelled |
Cancelled with the run |
skipped |
Not executed |
Gate banner. When one or more jobs are parked at waiting-approval, a banner appears above the graph. Each parked gate reads, for example:
Release/deploy is waiting for a deploy approval to
production.
with Approve deploy and Reject buttons. See Deploy gates & approvals.
Run controls. The header offers, depending on the run's state:
| Control | When it appears | What it does |
|---|---|---|
| Cancel run | Run is active (running or waiting-approval) |
Cancels every pending, running, and awaiting job |
| Re-run failed (N) | The run has failed/blocked jobs | Resets just the failed/blocked/cancelled jobs and restarts the ready frontier |
| Re-run all | Always | Resets every job and restarts from the first column |
| Proposal | Always | Jumps to the proposal/review page for this run |
Individual job nodes also carry a re-run button (for jobs in a terminal state: success, failure, blocked, or cancelled).
Job detail: steps, logs, timing, artifacts¶
Clicking a job node opens the job detail: breadcrumbs back through the run, a headline with the check name and its state pill, tags (environment, manual gate, matrix key), and a facts line (duration, step count, run id, attempt). Failures and blocks surface an annotations banner at the top of the page.
Four tabs organize the detail:
- Steps — each step is an expandable disclosure showing its status icon, name, command, and duration. A failed step auto-expands so the error is visible without a click. Step logs render as numbered monospace lines with
##[group]fold headers. - Logs — the full combined log for the job, with a copy button and the reminder: Secrets are masked as
***. (See Secrets.) - Artifacts — the artifacts the job produced (name · size · retention), each with a Download control.
- Timing — a per-step duration waterfall with the job total.
Secrets are never printed in cleartext. Any secret reference resolves to
***in the logs — you'll see lines likeAuthenticating with DEPLOY_KEY=***andAuthenticating registry with REGISTRY_TOKEN=***.
Note: on a live run the detail is only as rich as the wire. A job's execution record carries its step names, commands, statuses, timings and annotations, but never the log bytes — a step carries a reference and a window into the job's read-gated log stream, not its contents. Artifacts are real on a live run (they come off the blob plane), so the Artifacts tab always renders them. When a live job reports no steps at all, the Steps, Logs and Timing tabs degrade to one honest empty state rather than fabricating a breakdown:
Step and log detail streams from the job runner and isn't surfaced here yet.
A live job that does report steps renders the ordinary views: the Logs tab still draws its ##[group] folds and Timing still draws its waterfall, both from the live record — but each fold is empty, because the bytes are not in it. Only the filled-in log lines belong to the demo SEED.
Workflow detail & the Source tab¶
The workflow detail shows the workflow's name, path, and job count, the environments it deploys to, and a copyable status badge that reflects the workflow's real last-run status (passing / failing / running / pending). Two controls sit in the header: an Enable / Disable toggle, and a Run workflow disclosure (manual dispatch) that expands to a form of the workflow's declared inputs and a Dispatch button.
Four tabs:
- Jobs — the workflow's definition graph (jobs by id and
needs, withruns-onand matrix/env/gate tags), drawn with the same DAG geometry as a run. - Source — the authored source (see below).
- Runs — recent runs of this workflow.
- Triggers — change events, manual dispatch (with its inputs), and schedule (cron).
The Source tab adapts to how the workflow was authored:
- For a YAML workflow, it shows the
.ymlfile with a copy button and the file path. - For a config-as-code pipeline, it shows the authored SDK source file (with its content-address), then a disclosure labeled:
Compiled IR — the DAG the Forge registers (same shape as YAML)
Expanding it reveals the compiled intermediate representation — the exact DAG the Forge registers, in the same shape a YAML workflow lowers to. This makes it visible, side by side, that a config-as-code pipeline and a YAML workflow produce the same DAG.
(The Source tab only displays the two front-ends. The SDK API and YAML syntax themselves are covered in their own sections.)
Insights (analytics)¶
The Insights tab summarizes the repo's pipeline history. It opens with a scope line — how many runs are loaded, and the timestamp window they actually cover — then five panels:
- Run outcomes — a pass rate (passed ÷ passed + failed + blocked) over the completed outcomes, a breakdown of passed / failed / blocked / active / cancelled-skipped-unknown, and a footnote counting what is awaiting approval or queued. Active, cancelled, skipped and unknown runs are excluded from the rate.
- Recorded duration — average, median and 95th percentile, plus a sparkline over the last N runs.
- Workflow reliability — a table of workflow, pass rate, average run duration, and latest run (linking to it).
- Slowest observed jobs — ranked by average job duration, each with its sample count and longest observation.
- Recent failures — the first five loaded runs whose phase is failed, blocked or failing, with a Recurring failed and blocked jobs disclosure counting repeats by check name.
A Reported compute disclosure at the foot carries CPU minutes, GiB-seconds and job invocations.
Every number here distinguishes zero from unmeasured: a metric nobody reported renders as an em dash, never as 0. The compute totals appear only when every loaded run reports that measurement, and the panel says plainly that these are usage measurements, not billing estimates. Note that run-level metering is a SEED fact — the wire rows behind a live read carry none — so on a connected repository those totals are dashes and the run header shows no cpu-min.
Environments & deployments¶
The Environments tab lists each deployment environment with its protection summary (required-approver count, or no gate), an optional wait-timer pill, the current deployment, and a full deployment history table: status, commit, run (linking back to the run detail), who deployed, and when. A footer links to Settings › CI/CD to manage environments.
Last reviewed September 9, 2026
Suggest an improvement to this page Not for security reports — see disclosure