Because a px workspace is just files, a git repo can be the source of truth for your Prometheux ontologies — validated on every pull request and applied on every merge. px runs headless in CI: authenticate with environment variables, no interactive login.

Authenticate in CI

Skip px login and set two environment variables (they override any stored config):
Store them as repository secrets. Any datasource secrets your files reference as ${ENV_VAR} must also be present in the environment at apply time.

Validate on pull requests

validate is fully offline — no token, no platform — so it’s a fast, cheap PR gate:
--strict turns warnings into failures so a PR can’t merge with, for example, a concept-less ontology.

Apply on merge to main

Run px plan before px apply in the job so the diff (including the downstream re-run cascade) is captured in the build log for review/audit.

Sync the context layer

Apply the context layer the same way. Commit .px/context-state.json so the sync stays idempotent across runs:

Exit codes for gating

CI can gate on exit codes directly (see the command reference):
  • px validate0 PASS, non-zero FAIL.
  • px apply0 on success; non-zero if any concept was skipped (with a summary) or on a hard error — so a partial apply fails the job.
  • px plan, px status0.

Idempotency & state to commit

  • Project id in ontologies/<slug>/prometheux.yaml — commit it so re-apply targets the same ontology (never creates a duplicate). If it’s lost, apply reconciles by ontology name.
  • Context state .px/context-state.json — commit it so context apply updates rather than re-creates notes.
A clean checkout that’s already in sync plans as no changes — so re-running the apply job is safe.

Corporate runners

px honours HTTPS_PROXY, NO_PROXY, PIP_INDEX_URL, and REQUESTS_CA_BUNDLE / SSL_CERT_FILE, so it works on locked-down self-hosted runners behind a proxy with a corporate CA. Install the signed wheel from your internal mirror instead of the public one-liner. See Installation → Corporate install.