CI and workflows
Invariant fits into the workflow you already have: run locally before pushing, gate pull requests, run nightly on main, and collect evidence before a release.
The four stages
| Stage | Trigger | Default gate | Output |
|---|---|---|---|
laptop | invariant run laptop | none, informational | Terminal |
pr | Pull request opened or updated | block on worse | Status check and comment |
nightly | Schedule on main | alert on worse | Report, chat alert, first bad commit |
release | Tag or manual | all scenarios unchanged or better | Release evidence report |
Any CI system MVP
The CLI is the integration. It returns a meaningful exit code and can write a Markdown summary, so it works in GitHub Actions, GitLab CI, Buildkite, Jenkins or anything that runs a shell command.
| Exit code | Meaning |
|---|---|
0 | Gate passed. Warnings (inconclusive, flaky) are written to the summary and annotations. |
1 | Gate failed: a blocking verdict such as worse. With --strict, warnings fail the gate too. |
2 | Invalid command, spec or missing inputs |
3 | Incomplete: infrastructure failed after retries, so there is no passing verdict. Rerun the job; don't treat missing evidence as a pass. |
.gitlab-ci.ymlinvariant:
stage: test
tags: [gpu]
script:
- invariant run pr --compare origin/main --summary summary.md
artifacts:
when: always
paths: [summary.md]
Pull request checks and comments Next
With the repository app installed, Invariant posts a required status check and a single comment per pull request that it updates in place: verdicts that matter first, a one-click action to add runs to inconclusive scenarios, and links to each run's MCAP at the moment of failure.
Finding the first bad commit Next
invariant bisect --suite nightly --scenario dock_approach_02 --good v1.4.2 --bad mainWhen a nightly result gets worse, Invariant bisects the commits between the last good and first bad nightly, running only the affected scenarios, and reports the commit that caused the change.
Chat alerts Next
Nightly and release results can go to Slack, Microsoft Teams or a webhook. Alerts include the scenario, metric, size of the change and first bad commit, not just "nightly failed".
Coding agents and MCP Next
An MCP server exposes Invariant to coding agents: list suites, run a suite against a branch, read verdicts and fetch the failing run's details. An agent can test its own change on the laptop suite before opening a pull request. Agents use the same budgets and permissions as people.
Release evidence Later
A release report lists every scenario run, the versions of everything involved, the verdicts and the open warnings, exported as PDF and JSON. It's designed to answer "what did you test before shipping this?" for customers, safety reviews and your own post-mortems.