Skip to content

Track v0.4.0 production graduation #112

Description

@ErenAri

Objective

Graduate only the supported CLI + GitHub Action + disposable QEMU/KVM validation boundary to stable v0.4.0. The API/UI demo, runtime loading, agent, registry, SaaS, Firecracker, and virtme-ng remain experimental and explicitly out of scope.

This issue is the audit trail and checklist. Manual runs are shakeouts only and do not count as scheduled graduation campaigns. The earlier Yusuf-dependent review contract was superseded by the solo-maintainer design merged in #114; historical comments remain below as audit history.

Solo-maintainer release controls

  • main requires strict status checks, admin enforcement, conversation resolution, and blocks force-pushes/deletion, with zero required human approvals
  • production-release has no human reviewers, a 15-minute wait timer, no admin bypass, and an exact v* deployment policy
  • Active immutable v* tag ruleset blocks update/deletion and has no bypass actors
  • Tag workflow can only build, attest, sign, and stage a private draft
  • Separate workflow_dispatch promotion must run on the exact tag and re-verify the candidate run ID, full commit, digest, typed confirmation, draft assets, checksums, attestations, Sigstore signatures, image version, and release channel
  • Live scripts/check-production-environment.sh passes in solo-maintainer mode
  • Deprecated actions/attest-sbom wrapper migrated to pinned actions/attest in ci: migrate SBOM attestations to actions/attest #116; all 10 PR checks and post-merge workflows passed

Release candidate

  • Immutable annotated v0.4.0-rc.3 tag resolves to cba1e09537f2e05e4ba7278efdb5c2d044d1889b
  • Candidate run 30552866250 passed release quality, amd64/ARM64 build, native ARM64 execution, positive VM validation, classified-negative VM validation, multiarch image/version verification, signing, provenance, SBOM, and evidence attestation
  • Candidate evidence binds run 30552866250, attempt 1, the exact tag/commit, prerelease channel, and image digest sha256:842ebbc5746dcfcf98823407a762bdf379e24beb8ea20941ff77f9a74a1a2ac6
  • Exact-input promotion run 30553637272 waited 15 minutes, re-verified all bindings, and succeeded
  • GitHub release is a public prerelease with ten verified assets
  • GHCR RC tag is amd64+arm64 at the evidence digest; stable 0.4 was not created and latest stayed at sha256:4858cedde87681b1af4876bb8c869c7c1df0f5721764448a47042fe616e65102

Pre-campaign operational work

  • Deploy RC3 to the public demo at bpfcompat.kernelguard.net while keeping it visibly Technical Preview and outside the production claim
  • Verify public /livez, /readyz, HTTPS/security headers, KVM, watchdog, runtime-execute disabled, exact version/commit/checksum, and retained rollback binary
  • Resolve or explicitly disposition the seven stale enterprise-kernel baselines in Stale kernel baselines (weekly freshness report) #89 before campaign 1
  • Execute and record a deliberate release-promotion rollback drill using immutable before/after image digests, exact operator, commands, elapsed recovery, signature/provenance/version verification, and [bpfcompat-rollback-drill:v1]
  • Exercise and record the promotion incident path, proving an invalid deployment remains fail-closed

Four scheduled campaigns

Only schedule events from .github/workflows/latest-kernel-compatibility.yml count. Each must be unique, chronological, 6–8 days apart, complete within 120 minutes, have target p95 <= 12 minutes, and contain zero infra_error targets.

  • Campaign 1 — scheduled run 30790938510 on 2026-08-03
  • Campaign 2 — Monday 2026-08-10 03:21 UTC
  • Campaign 3 — Monday 2026-08-17 03:21 UTC
  • Campaign 4 — Monday 2026-08-24 03:21 UTC

For every run, record the workflow URL, artifact name, commit SHA, start time, report SHA-256, target status summary, infrastructure-error count, p95 target duration, and total workflow duration. Any supported-boundary behavior change after the window starts requires a new RC and restarts the window; documentation/release-tooling-only changes do not.

Independent ecosystem and consumer evidence

  • Capture the first successful scheduled Falco run after falcosecurity/libs@f6fed8e / falcosecurity/libs#3061
  • Verify the Falco artifact hash and expanded RHEL-family profile coverage
  • Run clean-install, source-build, Action, container, and external-consumer canaries against RC3
  • Verify 24-hour and 72-hour post-publication canaries; investigate every failure before graduation

Post-v0.4 ecosystem follow-up (not a v0.4 gate)

Confirmed adoption is a 1.0 ecosystem-readiness goal, not a technical prerequisite for the supported v0.4 boundary and not a substitute for its evidence.

  • Invite at least two controlled pilot evaluations through the adopter issue form without claiming adoption or endorsement
  • Record any confirmed public pilot only with explicit listing permission in ADOPTERS.md

Stable-release gate

  • Download the four campaign artifacts, expanded Falco artifact, candidate evidence, rollback note, incident note, and canary evidence into one private evidence directory
  • Build readiness/input.json with exact relative paths and SHA-256 values plus the solo operator confirmation marker
  • Run scripts/production-readiness-report.sh readiness/input.json readiness/bpfcompat-0.4.0-readiness.md without the test-only attestation bypass
  • Commit docs/releases/bpfcompat-0.4.0-readiness.{md,json} in the final release PR
  • Set stable_version: 0.4.0, release_version: 0.4.0, and release_channel: stable
  • Tag only the reviewed merge commit, complete the exact-input wait-gated promotion, and publish
  • Verify release assets, signatures, SBOM, provenance, image aliases, installer defaults, Action consumption, and stable canaries at 24h and 72h

Earliest defensible stable release: 2026-08-24/25, only if every gate passes and the campaign window is not reset.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions