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. Verify the release's origin, pin its exact archive digest, and install the complete distribution into a fresh directory:

one bundle install \
  --archive one-linux-x86_64.tar \
  --digest sha256:<verified-archive-digest> \
  --platform linux-x86_64 \
  --destination /absolute/path/to/one-installation

Prepare the project through the installed distribution before invoking workflow activities. Keep the accepted source and lock exact; dependency updates belong in a separately reviewed change:

one setup --distribution /absolute/path/to/one-installation/distribution --offline
one check --offline --format json
one test --offline --format json

Each fresh runner needs that preparation. An earlier job's successful setup is not an installed toolchain in a later job. Retain the installation report and transport the exact owner evidence needed by each dependent activity.

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 --root OrdersWeb --build-credential-input workload-credential.json

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.

Workload identity end to end#

The requirement is declared, then exchanged:

require one.authority#WorkloadAuthenticate@1(
    issuer: "https://token.actions.example"
    audience: "one-build"
    subject: repository("muijf/one", ref: "refs/heads/main")
)

The declaration is not a token, trust decision, or grant. The exchange returns one short-lived scoped credential:

{
  "principal": "workload:repository/muijf/one",
  "subject": "build:sha256:…",
  "scope": ["build:execute"],
  "expires_in": "10m",
  "epoch": "authority:epoch:204"
}

Issuer signature, audience, subject, repository/ref claims, time, nonce, revocation epoch, and policy are validated independently, and the credential is bound to the exact Build subject:

one invoke one.authority.workload#Exchange@1 workload-exchange.json
one build --root OrdersWeb --build-credential-input workload-credential.json

Stop release automation before mutation#

one release production build:sha256:<build-digest> --format json
one inspect plan:sha256:<hex> --subject changes
one approve plan:sha256:<hex> --decision approval.json
one apply plan:sha256:<hex>
one inspect operation:sha256:<hex>

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.

Repository verification can select ordinary Artifact test roots for Cargo formatting, workspace tests, and TypeScript libraries. The same application-test callback retains their Build report, test evidence, stdout, and stderr, and the verification bundle checks those records against the exact root and workflow input. The hosted workflow does not acquire a separate compiler command path.

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