CI Pipeline Output Generator

Believable CI logs for demos and tests

CI dashboards, status badges, and DevOps tools all need example pipeline output to render and test against. This tool generates a realistic CI/CD run: ordered stages, per-step timing, pass or fail markers, log snippets, and a final summary line, with the option to inject a failure that aborts the run.

How it works

A seed drives a mulberry32 pseudo-random generator, so the same seed always yields the same durations and layout.

• Each stage gets a random duration between roughly 3 seconds and 2 minutes, formatted as m s.
• A passing stage shows a check mark, its time, and a snippet such as 214 passed, 0 failed.
• If you inject a failure at a stage index, that stage shows a cross, an error line, and every subsequent stage is marked SKIPPED.
• The final line reads Pipeline SUCCEEDED in ... or Pipeline FAILED after ....

Tips and notes

Use the success mode for happy-path screenshots and the failure mode to test how your dashboard renders aborted runs and skipped steps. Reuse the same seed in automated tests so your fixtures are deterministic. The stage names follow a common build-test-deploy convention, which makes the output recognizable to most engineers.

Why reproducible fake CI output matters

When building or demoing a CI dashboard, monitoring tool, or DevOps integration, you need pipeline data that:

1. Looks realistic — real engineers will notice output that doesn’t follow the conventions of actual CI systems. Stage names, timing formats, and pass/fail markers all need to match the genre of output real tools produce.
2. Is controlled — you need to be able to show specific states: a fully green run, a run that fails at the lint stage, a run that fails at the deploy stage. You cannot rely on triggering real failures in a live system for a demo.
3. Is deterministic — if the same input always produces the same output, your automated tests become stable. A random seed that changes every run means your UI test fixture changes too, making screenshot comparisons unreliable.

The seed-based generator addresses all three: the output looks like a real CI run, the failure point is configurable, and the same seed always produces identical output.

What goes into a realistic pipeline log

A typical CI run follows a predictable lifecycle that most engineers will recognise immediately:

[Checkout]           ~ 2–5 seconds   Cloning repository and checking out branch
[Install deps]       ~ 20–60 seconds npm install, pip install, bundle install
[Lint]               ~ 5–15 seconds  ESLint, Flake8, RuboCop
[Type check]         ~ 10–30 seconds tsc --noEmit, mypy
[Unit tests]         ~ 15–90 seconds Jest, pytest, RSpec with coverage output
[Build]              ~ 20–120 seconds Webpack, Vite, cargo build, go build
[Integration tests]  ~ 30–180 seconds Tests against a real DB or API
[Deploy]             ~ 10–60 seconds Push to staging or production

The generated output mimics this rhythm: shorter stages early, heavier work in the middle, and a deploy at the end. Duration values are randomised from the seed within realistic ranges for each stage type, so the total time looks plausible rather than uniform.

Failure modes and what they look like

A pipeline failure in a real CI system short-circuits: the failed stage exits non-zero, subsequent stages are skipped, and the final summary reports failure with the total elapsed time up to the abort. The generator reproduces this exactly — inject a failure at the “Unit tests” stage, for example, and you get a crossed-out tests line with an error snippet, then every stage below it marked SKIPPED, then a Pipeline FAILED after 1m 47s summary.

This makes it straightforward to test that your UI handles the failure case: the badge turns red, the failed stage is highlighted, the skipped stages are greyed out, and the duration is correct.