TIDEFORGE ACTION CACHE
Tideforge identifies a package build by canonical declared inputs rather than a workflow run. The key covers the complete recipe directory, selected target and architecture, the selected target's contract and dependency-capability slice, the immutable OCI build-image digest, the package-format renderer set, dependency action keys, and the reproducibility contract including SOURCE_DATE_EPOCH.
Only renderer inputs used by a target are hashed: a Debian assembler change does not invalidate RPM, Arch, or openSUSE actions. Every build image is resolved to an image@sha256 digest before key generation.
An ActionResult records the exact action key plus every artifact's safe basename, byte size, and SHA-256. Restore verifies the requested key, schema, unique safe filenames, sizes, and hashes before a result may skip compilation. Lint, clean-install, and smoke validation still run on hits.
GitHub Actions cache is an acceleration transport. Workflows restore before
compilation and save only after all validation; the cache action never saves
implicitly. R2 uses actions/sha256/<action-key>.json as the authoritative
result index and blobs/sha256/<artifact-digest> for immutable content. A
lease for an action key is at leases/sha256/<action-key>.json. Only jobs
on the protected main branch can publish trusted R2 results. They write
the blobs first and the ActionResult last.
Authoritative CAS promotion and lease contract
-
CAS layout:
actions/sha256/<action-key>.json: the ActionResult. It is the commit marker.blobs/sha256/<artifact-digest>: the artifact bytes, by digest.leases/sha256/<action-key>.json: the lease for an action key.
-
Leases:
- A worker gets a lease of 30 to 45 minutes before it builds or promotes (
scripts/tideforge-action-cache.py acquire-lease). - A worker without a valid lease cannot promote to the CAS.
- When a lease expires, other workers look for a valid ActionResult.
- A worker gets a lease of 30 to 45 minutes before it builds or promotes (
-
Order of the commit:
- The promote step verifies each blob, then writes it (
blobs/sha256/<digest>). - The promote step writes the ActionResult (
actions/sha256/<action-key>.json) last. - Thus, when an ActionResult is in the CAS, each blob that it refers to is also there.
- The promote step verifies each blob, then writes it (
-
Promotion behind the factory boundary:
- Publication reads the ActionResults, verifies the digests and copies the bytes into the repository indexes.
- Builds on the protected main branch publish ActionResults and blobs to R2.