Gradle Cache Internals
What lives inside the Gradle user home, what is portable across machines, and what must be excluded.
IMPORTANT: Developer documentation for the current development branch. This content is unreleased, may change without notice, and must not be treated as Buildish release documentation.
Architecture & Background
Design documents covering the internal architecture of Buildish Mammoth Cache for Gradle and Maven.
These documents describe the internal design of Mammoth Cache — intended for contributors, maintainers, and anyone who wants to understand why the action behaves the way it does.
The core model is shared between Gradle and Maven: the same two-phase lifecycle, cache model,
key generation, delta exchange protocol, and CI abstraction layer underpin both. Build-tool-specific
behaviour is isolated behind a BuildToolAdapter interface so the shared phase logic never imports
tool-specific code.
Maven Cache Internals
What lives inside the Maven local repository, what is portable across runners, and what must be excluded.
Base Cache Design
Base cache restore/save lifecycle, timestamp garbage collection, prune-managed cleanup, and the distributed delta exchange model.
Cache Generations and Restore Lineages
How compatible cache families, ref lineages, and immutable generations are constructed and restored.
Delta Exchange Protocol
How Mammoth Cache packages, names, and exchanges per-worker cache deltas between distributed jobs.
Bootstrap Process
How the action initializes configuration, the cache model, and the build tool adapter (Gradle or Maven) before handing off to the build.
Gradle Wrapper Provisioning
How the action discovers, downloads, and verifies gradle-wrapper.jar files before the build runs.
CI Abstraction Layer
How the action separates CI-platform-specific logic from the shared core, and the rules that keep new provider adapters honest.