Skip to content

Release evidence checklist

Use one completed copy of this checklist for each candidate release. It is a review record, not a substitute for the signed reports, packet captures, and test artifacts it references. Do not mark an item complete from a console message, a passing unit test, or a report from a different build.

The approval rule and support boundary are defined in release readiness. The operator workflow for creating an accepted synthetic population is in the lab acceptance runbook.

Candidate identity

  • [ ] Community version, immutable commit, build SHA-256, and build time are recorded.
  • [ ] The Community controller reports a non-dirty version and a hexadecimal Git commit. --release-evidence rejects a development or unknown build identity before it contacts PVE.
  • [ ] PVE/PBS major versions, node build, storage profile, guest image IDs, controller build, node-worker build, and report-signer fingerprint are retained with the candidate.
  • [ ] The release notes enumerate the exact supported boundary and exclusions; no sales, release, or support claim exceeds the retained evidence.

Safety prerequisites

  • [ ] The approved synthetic fixture inventory and compatibility qualification audit passed without reducing the intended support population.
  • [ ] Every selected source has a current approved snapshot and the selected PBS mapping is read-only.
  • [ ] The restore zone/VNet has no gateway, SNAT, routed path, or physical uplink. Packet-capture evidence is retained.
  • [ ] If source VLAN/IP addressing is reused, the retained isolation attestation binds the exact source and restore VLAN/CIDR/zone/VNet and affirms the disconnected L2 boundary.
  • [ ] Every HTTPS fixture has a certificate SAN matching its declared probe name (or target IP) and a chain trusted by the PVE node worker. The retained fixture record identifies the approved CA/trust-store fingerprint; TLS verification bypasses are absent from every generated plan.
  • [ ] The controller environment, signing key, report keyring, and generated cases are access-controlled and absent from the evidence bundle.
  • [ ] The PVE API uses a verified certificate chain. PVE_TLS_INSECURE is absent; --release-evidence rejects the disposable-lab TLS override.
  • [ ] No report, controller log, or support bundle contains repository strings, credential material, private-key paths, or unredacted environment files.

Campaign evidence

For each suite, retain campaign.meta, plans.tsv, cases.tsv, generated plans and manifest, signed reports, report-verification output, and clean teardown evidence. A signed report counts only when its plan digest, candidate build identity, pinned signer, full-integrity mode, and node match this checklist.

  • [ ] Full healthy-fleet plan: all declared targets completed with all_passed: true and teardown_evidence.all_cleaned: true.
  • [ ] Individual plan for every supported source VM completed with the same signed pass and clean teardown requirements.
  • [ ] OS/image and network-manager representatives cover every supported backend.
  • [ ] Service-family plans and all required pairwise service-family plans completed.
  • [ ] Single- and multi-SCSI-disk layouts, firmware, machine, controller, NIC/MAC, CPU/RAM/balloon, and storage-profile combinations in the published boundary completed.
  • [ ] Each offered network lifecycle completed: preprovisioned isolation and, if supported, ephemeral create/reload/destroy with exact-owned cleanup.
  • [ ] A safe worst-intended concurrent tier passed, and an unsafe over-capacity plan was denied before any mapping, overlay, sandbox VM, or SDN mutation.
  • [ ] Each supported probe family has one injected fault whose report shows exactly the expected VM, protocol, and probe-description failure; collateral failures do not count as a fault-test pass.
  • [ ] Controlled interruption/recovery drills at mapping, overlay, boot, and probe phases left no owned VM, loop, overlay, host address, or ephemeral SDN resource.
  • [ ] Upgrade and rollback drills from every prior supported version completed a known-safe signed validation and report verification.

Code, package, and documentation gates

  • [ ] The intended Community release uses a stable vMAJOR.MINOR.PATCH tag, and CHANGELOG.md has a dated section for that exact version. The release workflow rejects malformed tags and an Unreleased changelog entry before it builds or publishes an artifact.
  • [ ] The CHANGELOG.md section for the candidate version carries the release date (## [x.y.z] - YYYY-MM-DD) and [Unreleased] has been emptied in the release commit; the workflow refuses an undated section.
  • [ ] Community tests, race tests, vet, coverage-generator/audit/helper tests, binary build, and artifact signing/checksum verification passed for the candidate commit.
  • [ ] A release signer verified the published checksum manifest through a separate trusted public-key channel.
  • [ ] The release workflow's protected GPG private-key, passphrase, and independently managed GPG_RELEASE_PUBLIC_KEY secrets are available only to authorized maintainers; the public signing-key fingerprint and independent retrieval channel are recorded with the candidate.
  • [ ] An operator who did not implement the candidate exercised Community installation, configuration, report verification, operations, troubleshooting, upgrade, and rollback instructions.

Final release decision

Record the reviewer, date, candidate identity, support boundary, and links or paths to the retained artifacts. Approval is valid only when every applicable item above is evidenced and every campaign summary is complete. Any missing, ambiguous, unsigned, unpinned, skipped-integrity, or unclean result is a release blocker until it is re-run successfully or the affected configuration is removed from the published support boundary.