Pipeline run
What it is
A pipeline run is a single concrete execution instance of a pipeline definition — a specific build/test/deploy identical to every other run of the same pipeline-yaml but with a distinct status, started time, inputs, and logs. Each time a trigger fires (a commit, a PR, a schedule, a manual dispatch), the system queues and starts a run.
Why it exists
Runs give CI its accountability and signal: teams need history (“which commit failed and why”), re-execution (rerun a failed job), and observability (a run has status/logs/artifacts) — not just a definition. A pipeline is the recipe; a run is one batch cooked from it.
Key ideas
- Run lifecycle: queued → running → succeeded / failed / cancelled / skipped; each stage/job has its own state.
- One definition, many runs: different triggers, vars, and inputs yield runs with the same shape but different results.
- Run artifacts & logs: every run keeps captured stdout/stderr and downloadable artifacts — the raw evidence for diagnostics.
- Rerunning / concurrency: failed jobs can be retried or re-queued;
concurrencylimits overlapping runs.
How it fits (diagram)
Exam notes
- Distinguish definition vs run: a YAML change does not run anything until next trigger — only a triggered run executes.
- Retry/back-off and timeouts apply per run/job, not to the definition globally.
- Runs are the unit of history and retention — purged runs free storage (see pipeline-maintenance).
Related
pipeline-maintenance · pipeline-variables · ci-trigger · pipeline-run-diagnostics-and-maintenance
📘 Source: What is Azure Pipelines? · Pipeline triggers and lifecycle