Pipeline Diet workflow: deterministic receipts, generated CI proposals and human review.

Inspiration

CI optimisation is only useful when someone can inspect why a change is safe. I built Pipeline Diet to turn pipeline records into reproducible receipts and proposals that still need human review.

What it does

The TypeScript CLI classifies changed paths, reads GitLab pipeline records, produces deterministic receipts and generates a proposed CI configuration. A guardrail compares candidates against policy and checker code from the trusted target branch. Security jobs remain protected. Numbers come from the CLI rather than an agent's estimates.

Two private GitLab Duo flows are configured: carbon-receipt handles completed pipeline events, and pipeline-diet handles requests for proposals. They are designed to orchestrate the CLI and post evidence for review. The final manual receipt replay launched its custom agent, but receipt production stopped at a GitLab API permission error. The installed catalog flows are private, while their authored YAML is in the public source repository. They do not deploy or merge changes.

How I built it

This is a Path B project built on the existing MIT-licensed go-httpbin workload. Its upstream history and attribution are preserved. I added the TypeScript tooling, GitLab CI configuration, policy checks and Duo flow definitions. A separate workload demo runs on Render's free plan. It demonstrates go-httpbin, not a web interface for Pipeline Diet.

Verified results and current limitations

The third hosted CI run is pipeline 2977078612 at commit 0e96fc93. Both Go versions (1.26.9 and 1.27.2), lint, GitHub Actions lint, SAST and secret detection completed successfully. The Diet suite passed 239 of 242 tests; three provenance tests failed because local Git clones attempted hard links across runner filesystems. The guardrail job was skipped after that failure. Scanner job success does not mean there are no findings: the earlier SAST report contains 14 findings with recorded triage and remaining limitations; it is not a clean-scan result.

The one-line test-helper repair is public on the proof branch at 273c8e12. All four provenance checks pass locally with it. The old complete local attempt is failed/incomplete, with 177 reported tests (164 pass, 4 fail, 9 cancelled); it is not a complete 242-test result. Independent isolated checks on that same proof source passed 13 deployment/mock tests and 18 CLI tests; the 13-test deployment file also passed on a second installed Node 24 patch version. These checks do not establish a complete passing suite. Hosted CI has not been rerun after this repair.

Two live Duo receipt attempts failed during startup before the custom agent executed: first a missing curl dependency, then an incompatible Alpine runtime. The default branch now contains a pinned Debian-based Node 24 runtime repair at c948749c. The third and final approved Duo test manually replayed the recorded event for CI 2977078612: session 9903508, workload pipeline 2977349867, job 17388793896. The repaired runtime launched the custom agent, which ran node diet/src/cli.ts flow-receipt --project 87894462 --pipeline 2977078612 --mr 1 --post --out-dir /tmp/diet-receipt. The command exited 3 on HTTP 403 when reading that pipeline's variables. The workload job passed, but the receipt did not complete. This was a recorded-event replay, not a new CI run or proof of the automatic pipeline trigger. Its network-policy settings are declarations; no enforced SRT network-isolation claim is made. Receipt triggers are paused. There is no completed hosted Duo receipt or proposal yet.

The proof merge request remains a draft and is unmerged. No measured time, cost or carbon savings are claimed. Google Cloud deployment templates remain disabled; the live workload uses Render Free.

Public evidence: CI run 2977078612, Duo workload 2977349867, and draft proof MR !1.

What I learned

Runner details matter: process inspection tools, shallow Git history and filesystem boundaries all affected the same suite. I kept those failures visible and separated local checks from hosted results.

What's next

Verify the published clone fix in hosted CI, resolve the receipt API permission limit, then demonstrate a completed receipt and a safely refused or reviewable proposal against real pipeline history.