Runs and logs
Every execution a repository can replay as evidence: CI workflow runs, Sigbound AI reads, verify and land runs, in one ledger with their logs.
Kinds of run
A run is one piece of work with a lifecycle: it is queued, claimed by a dispatcher, executed, and answered for afterwards. The ledger names each row by what it did:
| Row | What ran |
|---|---|
CI (the workflow file, e.g. ci.yml) | A workflow from .sigbound/workflows or .github/workflows, one job per sandbox. See CI. |
| Sigbound AI | One read of an attempt's head against the goal: the cited description and the verdict, on the platform's key. See Sigbound AI. |
| Verify | The gate's own check of the attempt before it lands. |
| Land | The landing itself: the merge, and the signed merge record. See Signed merges. |
A run has one of eight states, and the state names are the ones the API returns:
| State | Meaning |
|---|---|
queued | Admitted and waiting for a dispatcher. |
claimed | A dispatcher holds it under a lease and is starting it. |
running | Executing. The holder heartbeats its lease. |
waiting | A workflow run that reached a job bound to a protected environment, held for a reviewer or a timer. See Environments and deployments. |
succeeded | Finished, and the result is a pass. |
failed | Finished, and the result is not. The reason is recorded on the row. |
cancelled | Somebody asked it to stop, with a reason, and it stopped. |
abandoned | Three dispatchers in turn died holding it. It is no longer claimable and is finished with that reason. |
The runs list
A repository's runs are at Runs in the repository header, with two views: All runs, the ledger, and Workflows, the catalog of workflow files. Each row names the kind, the attempt (attempt 7.1), the head it ran at, the state, the duration and when it ran. A run whose checks were reused from an earlier attempt says so (reused from 6.2).
The filter box takes qualifiers, re-queried on the server: state:running, goal:12, agent:, model:, change:, base:. The list covers the repository's retained ledger, a 90-day evidence window; a run older than that is absent, not failed.
The space's runs are at Runs in the space header: what is happening now across every repository, the latest rows from each, and the two caps. A space may have a bounded number of runs executing at once and a bounded number queued; a run past the first cap waits, a run past the second is refused at the door, and lowering a cap never stops accepted work. A space admin changes the caps on this page.
sigbound ci list sigbound do list_runs org=<space> repo=<repo>
The run page
A run's page opens from any row. The header states the kind, the attempt, the head, when it started and which try this is. For a workflow run the left column lists the jobs with their durations, then the evidence: the tries, the artifacts, the deployments, the signed attestation for this try, and the workflow file. The body shows the trigger, the status, the duration, the artifact count, then one card per job in the order needs says, each marked passed, failed, waiting for a person or a timer, running or skipped.
A Sigbound AI run's page shows the verdict and the cost of the read in place of the jobs, with its steps (the read, the model usage) and the same log box. A verify or land run shows its result and the steps the gate took.
Tries
A try is one execution of a run. A run whose dispatcher dies mid-way is claimed again by another, and that is the run's second try; a run may be tried at most three times before it is abandoned. Every try has its own log and its own signed attestation, and the run page's Tries chips switch between them. The header link reads try 1 of 1 for a run that needed no second try.
A re-run is different: it is a fresh run of the same immutable work, the same workflow file, event, pinned head and inputs, with its own log and checks, and the old run keeps its record. A finished workflow run has Re-run workflow; a failed one also has Re-run failed jobs, which re-runs every job whose check at this head is not a success and whatever depends on it. The API takes an optional selection:
POST /orgs/{space}/repos/{repo}/runs/{id}/rerun?at=…
{"failed": true} # or {"job": "build"}, or an empty body for the whole workflowLogs
A run's log is written as the run executes and can be read while it is live: the page shows a verified prefix of the stream and follows it. Each chunk is stored as an immutable object with its SHA-256, and a read that cannot verify its bytes refuses rather than returning a shorter log. One try's log is bounded at 64 KiB; beyond that the run keeps executing but the elided bytes are never written, and the page says so. Build products belong in artifacts, not the log.
For a workflow run the log is folded by job and by step, in order, with the runner's own chatter counted and hidden behind a toggle and a raw view available. The log stays readable for as long as the run is in the ledger.
sigbound run logs <run-id> sigbound do get_ci_log org=<space> repo=<repo> attempt=7.1 # the newest CI run at the attempt's head
Cancelling
A live run (queued, claimed or running) has Cancel this run on its page. A reason is required and goes on the record. For a queued or waiting run the cancel is immediate; for a run that is claimed or executing it is a request: the dispatcher holding the run sees it, stops the task, and finishes the run as cancelled. Cancellation is absorbing: remaining tries are discarded and the run's credential is revoked. A run that has already finished is not touched.
POST /orgs/{space}/repos/{repo}/runs/{id}/cancel?at=…
{"reason": "superseded by a newer push"}