CI integration
Provar runs the same in CI as on your machine. Install the CLI, point it at your tests, read the exit code. The CLI exits with the documented codes (0 / 1 / 2 / 130 from Running tests), so any CI system can report failures correctly without any Provar-specific glue.
provar-cli configuration
The product-shaped details (install pattern, environment variables, job shape, caching) live on the provar-cli page. This page covers the same ground from a CI-systems perspective — how to wire the CLI into GitHub Actions, GitLab CI, and other systems in a portable way.
Quick reference: install the CLI (one-line curl on macOS / Linux, raw binary on Windows),
the only secret you need is the LLM provider API key (write it into ~/.provar/settings.yml before invoking the CLI), and the canonical run command
is provar run ..
GitHub Actions
- name: Install provar CLI
run: curl -fsSL https://provar.se/install.sh | bash
- name: Run provar tests
run: prover run . GitLab CI
Same job, expressed as a .gitlab-ci.yml entry. The curl installer works on
Linux runners directly. Otherwise, pull the binary from the GitHub releases page and put it on PATH.
Secrets
The LLM API key is the only secret Provar needs. The CLI reads it from ~/.provar/settings.yml at compile time — pass it as a CI secret and write it
into the file in a pre-step:
- name: Write Provar settings
env:
PROVAR_OPENAI_KEY: ${{ secrets.OPENAI_API_KEY }}
run: |
mkdir -p ~/.provar
cat > ~/.provar/settings.yml <<EOF
models:
provider: openai
providers:
openai:
model: gpt-5.5
apiKey: $PROVAR_OPENAI_KEY
google:
model: gemini-3.5-flash
anthropic:
model: claude-5-sonnet-latest
EOF One thing to be careful about: never commit the key to the repo, and don't put it in .provar/config.yml — config files get diffed in pull requests. CI secrets are
the right home.
The compile step is the only step that touches the LLM. The run step is purely
local — no API key needed at run time.