Draaien in CI

CI gaten behandelt de releasepolicy en wat elke exitcode betekent. Deze pagina is het deel dat zich binnen een CI-job afspeelt: hoe je Oloproof daar installeert, waar het bewijs staat terwijl de job draait, hoe je een resultaat leest zonder een tabel te parsen, en hoe je een pull request vergelijkt met de branch waarop die gericht is.

De exitcode is de gate

oloproof run eindigt op zijn gate. Een CI-stap die hem draait, faalt wanneer de gate blokkeert, wat meestal is wat je wilt en geen extra bedrading vraagt:

Code 3 is degene waarover teams discussiëren. De standaardpolicy blokkeert erop, omdat een suite die te klein is om te beslissen niet heeft aangetoond dat de wijziging veilig is. Een team dat wil dat de job groen wordt terwijl het zijn suite uitbreidt, kan dat in de policy zeggen, in plaats van de exitcode te negeren:

version: 1
block_on: [FAIL, MANUAL_REVIEW]
warn_on: [INSUFFICIENT_EVIDENCE]
rules:
  - id: exact-label-floor
    metric: exact_label
    min: 0.70

Dezelfde opgeslagen run van examples/support_bot/, die met 3 blokkeert onder zijn eigen policy, onder deze:

oloproof gate RUN_ID --policy advisory.yaml

exact-label-floor: INSUFFICIENT_EVIDENCE (interval_overlaps_threshold)
  about 1614 more cases would decide it, if the observed rate holds (1632 in total)

Hij eindigt met 0. De beslissing is ongewijzigd. Alleen de releaseactie verschoof, en ze verschoof omdat een bestand dat wordt gereviewd dat zegt.

Het resultaat als data lezen

--json schrijft één JSON-event per regel naar standaardoutput en de tabellen voor mensen naar standaardfout, zodat een CI-log de tabellen houdt en een script de events leest. Opgeslagen in run.ndjson staat de id van de run op elke regel, en de laatste regel draagt de exitcode:

jq -r 'select(.type == "run_started") | .run_id' run.ndjson
jq -c 'select(.type == "run_finished")' run.ndjson

run_01M3C3WS0SBTFAG55M7ECM1EZ4
{"run_id":"run_01M3C3WS0SBTFAG55M7ECM1EZ4","timestamp":"2026-09-25T11:06:03.646415Z","type":"run_finished","status":"DECIDED","completeness":"COMPLETE","exit_code":3}

Voortgang en gelijktijdigheid somt elk eventtype op.

Waar het bewijs staat

Een run wordt opgeslagen in .oloproof/store.sqlite naast de oloproof.yaml waaruit hij werd gedraaid, en oloproof init zet .oloproof/ in .gitignore. Een CI-job begint met een lege store, dus elke job voert elke case opnieuw uit, en niets van de ene job is zichtbaar voor de volgende.

Dat doet er het meest toe voor een vergelijking, die beide runs in één store nodig heeft. Twee checkouts van een project krijgen elk hun eigen store, dus een baseline-run uit de ene is vanuit de andere niet te vinden:

Configuration error: unknown run 'run_01M3C3XSX9KY5T8VFZXA1CVBES'

OLOPROOF_HOME laat elke opdracht naar één store wijzen, waar zijn oloproof.yaml ook staat. De map die het noemt, bevat .oloproof/store.sqlite.

Oloproof in een job installeren

Oloproof is niet gepubliceerd in een package-index, dus er is geen pip install-regel die het op naam ophaalt. Een job installeert het vanuit een checkout van de Oloproof-repository, op dezelfde manier als een ontwikkelaar: actions/checkout met repository: dat noemt waar de kopie van die repository van je team staat, en een token: dat haar kan lezen als ze privé is. De root van de repository bouwt het package, en het package levert de opdracht oloproof.

Een pull request vergelijken met zijn basis

Check de basisbranch en de pull request naast elkaar uit, draai elk in dezelfde store, en vergelijk:

name: oloproof
on: pull_request
jobs:
  evaluate:
    runs-on: ubuntu-latest
    env:
      OLOPROOF_HOME: ${{ github.workspace }}/evidence
    steps:
      - uses: actions/checkout@v4
        with:
          path: pr
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.base_ref }}
          path: main
      - uses: actions/checkout@v4
        with:
          repository: YOUR_ORG/Oloproof
          token: ${{ secrets.OLOPROOF_REPO_TOKEN }}
          path: oloproof-src
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: python -m pip install ./oloproof-src
      - run: mkdir -p "$OLOPROOF_HOME"
      - run: oloproof run --config main/oloproof.yaml --json > base.ndjson || true
      - run: oloproof run --config pr/oloproof.yaml --json > cand.ndjson || true
      - name: compare
        run: |
          candidate=$(jq -r 'select(.type == "run_started") | .run_id' cand.ndjson)
          baseline=$(jq -r 'select(.type == "run_started") | .run_id' base.ndjson)
          oloproof compare "$candidate" "$baseline" --config pr/oloproof.yaml --policy pr/compare.yaml

YOUR_ORG/Oloproof en OLOPROOF_REPO_TOKEN zijn plaatshouders voor je kopie van de repository en een secret dat haar kan lezen. De twee runs dragen || true omdat hun eigen gates hier niet de vraag zijn; de exitcode van de vergelijking wel.

Dezelfde stappen op een laptop, met het opgezette project twee keer uitgecheckt:

Comparison sha256:31ac104779bda1726ba55b661107cbe256fae5f1d831c79b1283a07651b58cbf of run_01M3C3XX4TM0WSZW8K81PHRGAW against run_01M3C3XW7X64B0Z0ACZV27WSW6 · 30 paired cases
exact_label: +0.0 points [-16.5, +16.5] · 30 paired · 0 missing · 0 excluded
Decisions
  no-regression  exact_label  non-inferiority, margin 5.0 points  INSUFFICIENT_EVIDENCE  interval_overlaps_margin
Gate: BLOCK (exit 3)

Beide runs moeten over dezelfde suite gaan. Een pull request die een case bewerkt, verandert de digest van de suite, en de vergelijking weigert in plaats van cases te paren die niet langer dezelfde case zijn:

Configuration error: runs 'run_01M3C3XXVZ1X0J2PR1ZW1WVGVZ' and 'run_01M3C3XW7X64B0Z0ACZV27WSW6' used different suites (sha256:baff4f101901d9a37cd440f99b9a70032f9488891b4f590f18a81017c26ba794 and sha256:2011286a7ec00c8c31560bb6d037b54a501a15f6251ac7c2d578d0c40e226d72); comparisons pair scenario by scenario over one suite

Een vergelijking van een run die niet afliep, eindigt met 5, net als een gate over zo'n run: er is geen gepaard resultaat om over te beslissen.

Verder lezen

• CI gaten behandelt de policy en de volgorde waarin exitcodes worden gerapporteerd.
• Vergelijkingsregels behandelt wat een vergelijkingspolicy kan vragen.