CI Codegen Check

Use optixlog generate --check to fail a CI pipeline when committed bindings are stale, with example GitHub Actions steps.

optixlog generate --check compares what would be generated against the committed optixlog_gen.py (or package). If they differ, it exits with a non-zero status and writes nothing. Use this in CI to catch forgotten regenerations before they merge.

How --check works

Fetches the schema (or reads the fixture).
Generates the output in memory.
Compares byte-for-byte against the on-disk file.
If they match: exits 0, prints nothing.
If they differ: exits 1, prints a message to stderr, and does NOT overwrite the file.

The output is byte-deterministic, so the comparison is reliable: the same schema always produces the same bytes.

Basic usage

optixlog generate --check

Run this in your CI pipeline after checking out the repo. If optixlog_gen.py is up to date the step passes silently. If it is stale, the step fails with an exit code of 1.

GitHub Actions: offline check with fixture

This example uses the committed fixture to run the check with no live server dependency:

.github/workflows/codegen-check.yml

name: Codegen check

on:
  pull_request:
  push:
    branches: [main]

jobs:
  check-bindings:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install optixlog
        run: pip install optixlog

      - name: Login (fixture)
        run: |
          optixlog login \
            --fixture tests/fixtures/schema.sample.json \
            --api-key sk-opt-test \
            --base-url http://localhost \
            --no-input

      - name: Check bindings are up to date
        run: |
          optixlog generate \
            --check \
            --fixture tests/fixtures/schema.sample.json

If optixlog_gen.py is stale, this step fails with exit code 1 and the PR is blocked. The developer regenerates locally and pushes the updated file.

GitHub Actions: live server check

For environments where CI has access to a live OptixLog server, use a repository secret for the API key:

.github/workflows/codegen-check-live.yml

name: Codegen check (live)

on:
  pull_request:

jobs:
  check-bindings:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install optixlog
        run: pip install optixlog

      - name: Login
        env:
          OPTIXLOG_API_KEY: ${{ secrets.OPTIXLOG_API_KEY }}
        run: optixlog login --no-input

      - name: Check bindings are up to date
        run: optixlog generate --check

Keep OPTIXLOG_API_KEY in secrets

Never print OPTIXLOG_API_KEY in logs or commit it to the repository. Use GitHub Secrets (or your CI provider's equivalent) and reference it as an environment variable.

Combining --check with --dry-run

Use --dry-run during development to preview what would be generated without writing the file:

# Preview generated output.
optixlog generate --dry-run

# Check if committed bindings match, fail if not.
optixlog generate --check

--dry-run and --check are mutually exclusive — --check suppresses all output on success; --dry-run prints the full generated module to stdout.

Handling a stale-bindings failure

When CI reports stale bindings, regenerate locally and commit the result:

# Regenerate (live server):
optixlog generate

# Or regenerate offline:
optixlog generate --fixture tests/fixtures/schema.sample.json

# Review the diff, then commit:
git add optixlog_gen.py
git commit -m "chore: regenerate optixlog bindings"

Byte-deterministic output

Because the output is byte-deterministic, two developers running optixlog generate from the same schema always produce identical files. The --check comparison is therefore a reliable gating step.