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.

Single-Job Builds

Using Buildish Mammoth Cache in a workflow with a single build job.

Single-job mode (job-mode: standalone, which is the default) is the right choice when your workflow runs one build job at a time. The action restores the newest compatible immutable generation before the build and publishes a new complete generation only when managed state materially changes.

Gradle

For Gradle, the prepare step additionally provisions any missing wrapper JARs before handing off to your build.

sequenceDiagram
    participant P as prepare
    participant B as ./gradlew build
    participant F as finalize

    P->>P: restore cache (or cold start)
    P->>P: provision gradle-wrapper.jar
    P-->>B: hand off
    B-->>F: build complete
    F->>F: compare material state
    F->>F: publish complete generation if required

Minimal workflow

 1jobs:
 2  build:
 3    runs-on: ubuntu-latest
 4    permissions:
 5      contents: read
 6    steps:
 7      - uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd
 8      - uses: actions/setup-java@be666c2fcd27ec809703dec50e508c2fdc7f6654
 9        with:
10          distribution: temurin
11          java-version: '21'
12      - uses: buildish-tooling/buildish-mammoth-cache/actions/github/gradle@<commit-sha>
13      - run: ./gradlew build

Config file

1# .github/buildish-mammoth-gradle.yml
2cache-key-prefix: my-project-gradle-
3wrapper-properties-files: gradle/wrapper/gradle-wrapper.properties

1steps:
2  - uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd
3  - uses: buildish-tooling/buildish-mammoth-cache/actions/github/gradle@<commit-sha>
4    with:
5      config-file: .github/buildish-mammoth-gradle.yml
6  - run: ./gradlew build

Maven

For Maven the prepare step restores the local repository and finalize publishes a complete new generation when the managed repository materially changes. No wrapper provisioning is performed.

sequenceDiagram
    participant P as prepare
    participant B as mvn verify
    participant F as finalize

    P->>P: restore cache (or cold start)
    P-->>B: hand off
    B-->>F: build complete
    F->>F: compare material state
    F->>F: publish complete generation if required

Minimal workflow

 1jobs:
 2  build:
 3    runs-on: ubuntu-latest
 4    permissions:
 5      contents: read
 6    steps:
 7      - uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd
 8      - uses: actions/setup-java@be666c2fcd27ec809703dec50e508c2fdc7f6654
 9        with:
10          distribution: temurin
11          java-version: '21'
12      - uses: buildish-tooling/buildish-mammoth-cache/actions/github/maven@<commit-sha>
13      - run: mvn verify

Config file

1# .github/buildish-mammoth-maven.yml
2cache-key-prefix: my-project-maven-

1steps:
2  - uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd
3  - uses: buildish-tooling/buildish-mammoth-cache/actions/github/maven@<commit-sha>
4    with:
5      config-file: .github/buildish-mammoth-maven.yml
6  - run: mvn verify

Pull-request read-only mode

Both actions automatically switch to read-only on pull_request and pull_request_target events — no configuration needed. In read-only mode the cache is restored as normal but the finalize step skips the save, preventing untrusted fork code from poisoning the cache.

You can also force read-only mode explicitly with read-only: true for any event, or opt out with a direct read-only: false workflow input when you have a controlled-fork trust setup. A checked-out config file cannot lower the pull-request safety floor.

Next steps