Skip to content
DocumentationCI & release automation
On this page

Page resources

Open Markdownllms.txtView source

Last updated

CI runs the ordinary project lifecycle against explicit source, root, lock, tools, credentials, and output formats. A hosted workflow file is a disposable projection—not another project manifest, provider selection, or authority path.

Pin the complete input

Start from the checked-in one.one, every selected .one source, and exact one.lock. Install a verified One distribution, import any required offline bundle, and reject implicit resolution:

one inspect distribution
one sync --offline
one check --offline --format json
one test --offline --format json
one verify --offline --format json

Cache only content-addressed downloads and reconstructible outputs. A cache hit does not replace checksum, signature, provenance, tool qualification, or lock validation. Never cache protected credential inputs as build artifacts.

Authenticate the workload, not the runner image

Use the CI provider's OIDC assertion to request a short-lived credential bound to the exact repository, ref, root, Build subject, scope, policy epoch, and expiry. A declaration of WorkloadAuthenticate is only a requirement; the Authority exchange independently validates issuer, audience, subject, time, nonce, and revocation state.

one invoke one.authority.workload#Exchange@1 workload-exchange.json
one build plan:<revision> --credential workload-credential:<revision>

The Build credential cannot authorize apply, another ref, or a later Build. Keep planning, approval, grant issuance, and effectful apply as separate jobs when their authority or reviewers differ.

Stop release automation before mutation

one release production --format json
one inspect plan:<revision> --subject changes
one approve plan:<revision> --decision approval.json
one apply plan:<revision>
one inspect operation:<revision>

release produces release intent and immutable plans but never applies by name. Apply must revalidate exact source, lock, artifacts, evidence, approvals, grants, observations, and plan freshness. On runner loss after possible dispatch, resume or reconcile the existing operation: reference; do not start a fresh apply because the job appears failed.

Project the host workflow

Generate a supported CI format through its typed projection owner:

one export ci github-actions --root OrdersWeb

The output carries a receipt naming semantic inputs, root, generator, revision, deterministic bytes, source map, and every loss. Review it like any other generated operational artifact. Edit source or projection configuration, then regenerate; do not hand-maintain divergent semantics in YAML.

CI results should retain machine-readable owner records, Build reports, artifact identities, test and qualification evidence, approval decisions, operation journals, and History references. Human logs are useful presentation, not the evidence graph.

See use workload identity, qualify a release, and plan, build, and apply.