# CI and release automation 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: ```console 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. ```console one invoke one.authority.workload#Exchange@1 workload-exchange.json one build plan: --credential workload-credential: ``` 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 ```console one release production --format json one inspect plan: --subject changes one approve plan: --decision approval.json one apply plan: one inspect operation: ``` `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: ```console 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](/one/examples/workload-identity), [qualify a release](/one/examples/release-qualification), and [plan, build, and apply](/one/lifecycle/plan-build-apply).