View Results

This page walks through where to find pipeline runs in the dashboard and what each part of a run’s page shows. See How It Works for the underlying model.

The screenshots come from one real run of a small pipeline: a build step compiles and tests a Go program, then streams the binary to a smoke-test step that runs it.

Find a Run

1. Open Runs, under Execution in the dashboard. It lists every run of the organization, most recent first, with its status, mode, entrypoint, resources, instance, start time and duration. The direct run is the one you launched; each distribution run is a step the pipeline dispatched to a machine of its own.

2. Click a run to see a summary, or open it to reach its page.

3. Open Groups, also under Execution, to see the runs of one execution together: the direct run and every distribution run it started. From a run’s page, Go to Group leads there too.

Read a Group’s Page

A group’s page answers three questions: what ran, in what order, and what it cost in resources.

• The header names the entrypoint, when the group started and how long it has lasted, how many runs it has and in which state, and the resources they requested together: containers, volumes, memory, CPU and storage.
• Requested resources over time draws the memory and CPU the runs of the group requested, as they changed. Each run counts from its start to its end, or up to now while it runs. The time axis is real time: a step that lasted fifteen minutes takes five times the width of one that lasted three, and a gap between two steps shows as a gap. A plateau is steps running in parallel; a narrow spike is a short step that asked for a lot.
• Distribution hierarchy draws which run started which.
• The runs, then the artifacts of all of them.

The chart above comes from a release pipeline: a build of fifteen minutes, two test runs in parallel on two clouds, then packaging, which is still running. The two tests overlap, so their resources add up for the few minutes they share.

Read a Run’s Page

Header

The top of the run page shows the run’s status, its mode, the entrypoint that was launched, when it was requested, started and finished, and the tags and parameters it was launched with. A parameter typed Secret appears by its name only.

Renders and Artifacts

When the run kept artifacts, they come next. Renders shows those with an entrypoint, one tab per render: images, Markdown, tables from JSON or CSV, or a whole HTML page running on a domain of its own (see Renders). Artifacts lists every artifact of the run with its files, size, access and expiry. Download one in a click, copy its stable address, or open it to see its files, change its access and expiry, lock it, and read its history, depending on your role.

Pipeline Graph

Below the header, the pipeline is drawn as a graph of treatments and connections, reconstructed from the program that was actually executed. If the run produced debug events, a timeline runs under the graph: each colored mark is a group of events. Click one to zoom in, or move the cursor through the run.

The graph highlights the treatment or connection of the event at the cursor, among the ones it shows. A step is made of inner treatments: open it with the arrow on its node to follow its own events.

Resources

The page of a step’s run lists its parts: the Mélodium engine, the step’s container with its image, and the volume they share, each with the CPU, memory and storage it requested. Required Resources adds them up.

Logs

The Logs panel streams the run’s logs in near real time: it polls for new chunks every few seconds while the run is ongoing, and stops once the run has finished. Logs can be downloaded as a single file at any time, including while the run is still in progress.

Debug Data

Below the logs, the Debug Events panel lists the debug events captured during execution, one per line with its time and kind. It’s hidden by default: click Show to open it, and filter by kind, track or any field. The events can be downloaded the same way as logs. Runs reported with --api-report capture them at the basic level by default; see Debug Events.

Filtered on recvData.data, the events above show the build’s binary reaching the smoke test in four chunks of 4096, 1048576, 1048576 and 34046 bytes, 2135294 bytes in all, the size the build step printed; then the output closes.

Events relayed from the machines that ran the steps appear as distant, with the run they come from and the event itself. The secret audit appears too, recording which element used which secret, by name only: see What Goes Through Cadence.CI.

Going Further

• Connect a Cloud, how the instance running a given step was chosen.
• How It Works, what’s captured today versus what’s on the roadmap.