CI Integration

Non-interactive login, init, and generate in CI. Use generate --check to detect committed binding drift in GitHub Actions.

The optixlog CLI is designed to run non-interactively in CI. Pass --no-input to suppress all prompts and rely on environment variables or explicit flags for every value.

Key CI principles

Use --no-input on all commands to prevent the CLI from hanging waiting for input.
Inject OPTIXLOG_API_KEY from your CI secrets manager — never hardcode keys.
Use optixlog generate --check to detect drift between the committed optixlog_gen.py and the current schema, without writing any files.
Consider using a fixture (OPTIXLOG_FIXTURE) for the --check step so it runs offline without network access.

Non-interactive command patterns

optixlog login \
  --api-key "$OPTIXLOG_API_KEY" \
  --base-url https://optixlog.leidos.com \
  --profile ci \
  --no-input

Or let OPTIXLOG_API_KEY be picked up automatically (it has highest precedence for key resolution):

OPTIXLOG_API_KEY="$OPTIXLOG_API_KEY" optixlog login --no-input

Init

optixlog init \
  --all \
  --output optixlog_gen.py \
  --module-style single_file \
  --no-input

--all selects every accessible project. --no-input requires either --all or --project.

Generate (write)

optixlog generate --profile ci

Generate (check only — detect drift)

optixlog generate --check

Exits 0 if optixlog_gen.py is current. Exits 1 and prints an error to stderr if the file is stale or missing.

GitHub Actions example

Pattern 1: Offline drift check (recommended)

This job commits optixlog_gen.py in your main workflow and then checks in CI that the committed file is still current relative to the fixture. No network calls needed.

.github/workflows/check-bindings.yml

name: Check generated bindings

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 SDK
        run: pip install optixlog

      - name: Check bindings are up to date
        env:
          OPTIXLOG_FIXTURE: tests/fixtures/schema.sample.json
          OPTIXLOG_CONFIG_HOME: /tmp/optixlog-ci
        run: |
          optixlog login --api-key sk-opt-test --base-url http://x --no-input
          optixlog generate --check

If the check fails, the job output will read:

./optixlog_gen.py is out of date; re-run `optixlog generate`.

The developer must re-run optixlog generate locally and commit the updated file.

Pattern 2: Live regeneration in CI

Use this pattern when you want CI to regenerate and commit bindings from the live server on every push to main.

.github/workflows/regen-bindings.yml

name: Regenerate bindings

on:
  push:
    branches: [main]

jobs:
  regen:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4

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

      - name: Install SDK
        run: pip install optixlog

      - name: Authenticate
        env:
          OPTIXLOG_API_KEY: ${{ secrets.OPTIXLOG_API_KEY }}
          OPTIXLOG_CONFIG_HOME: /tmp/optixlog-ci
        run: optixlog login --no-input

      - name: Generate bindings
        env:
          OPTIXLOG_API_KEY: ${{ secrets.OPTIXLOG_API_KEY }}
          OPTIXLOG_CONFIG_HOME: /tmp/optixlog-ci
        run: optixlog generate

      - name: Commit updated bindings
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add optixlog_gen.py
          git diff --cached --quiet || git commit -m "chore: regenerate optixlog bindings"
          git push

init in CI

If optixlog.toml is already committed (the typical case), init is a no-op in CI — it skips silently when the file exists:

optixlog init --all --no-input  # exits 0 immediately if optixlog.toml exists

If you need to regenerate it, use --force:

optixlog init --all --force --no-input

Choosing a service-account key

In CI, use a service-type API key rather than a personal user key. Create it in the OptixLog dashboard or management API and inject it via your secrets manager.

env:
  OPTIXLOG_API_KEY: ${{ secrets.OPTIXLOG_SERVICE_KEY }}

The key_type field in whoami output will read service to confirm you are using the right key type.

Never echo OPTIXLOG_API_KEY

Do not print or log the value of OPTIXLOG_API_KEY in your CI scripts. Use optixlog whoami (which masks the key) if you need to verify which credential is active.

CI Integration

On this page