Deploys and the build pipeline

What the pipeline accepts

• A GitHub repository as owner/name, at a full commit SHA (40 or 64 hex characters). Branch names, tags and short SHAs are refused, so a build is always of an exact commit.
• A Dockerfile at the repository root. Builds without a Dockerfile (framework detection) are not available yet.

What every build goes through

1. Secret scan with gitleaks. Any finding fails the build. Ignore files and allow comments in your repository are not honoured.
2. Build with rootless BuildKit.
3. Bill of materials with Syft, in SPDX and CycloneDX.
4. Vulnerability gate with Trivy. A CRITICAL finding fails the build unless a waiver of 90 days or less, from a different named approver, covers it.
5. Signing with cosign (ECDSA P-256), plus attestations for the SBOM, SLSA v1 provenance and OpenVEX.

Every stage fails closed: if a tool is missing or errors, the build stops. Cells admit only images signed by this pipeline, enforced by Kyverno admission policies.

Deploying a build

A deploy is a change in a plan. In production it is a PROD_CHANGE. Add a canary (1–50% of traffic, a maximum error rate and a window of 60–3,600 seconds) and a release-only deploy can go out without an approver; the canary rolls the release back if errors rise.

{
  "kind": "deploy",
  "environment": "production",
  "imageDigest": "sha256:…",
  "newCode": true,
  "canary": { "percent": 10, "maxErrorRate": 0.01, "windowSeconds": 600 }
}

Not done yet

• Builds without a Dockerfile (Railpack or Cloud Native Buildpacks).
• Publishing to a registry in a running cell, and admission on a live cell.
• A public transparency log for signatures.