bitrise-steplib/bitrise-step-save-gradle-cache

Save Gradle Cache

Saves Gradle caches. This Step needs to be used in combination with Restore Gradle Cache.

Description

Saves Gradle dependency caches. This Step needs to be used in combination with Restore Gradle Cache.

This Step is based on key-based caching and sets up the cache key and path automatically for Gradle. If you'd like to change the cache key (or paths to cache), you might want to use the generic Save cache Step instead.

Related steps

Restore Gradle cache

Save cache

🧩 Get started

Add this step directly to your workflow in the Bitrise Workflow Editor.

You can also run this step directly with Bitrise CLI.

Examples

Check out Workflow Recipes for other platform-specific examples!

Minimal example

steps:
- restore-gradle-cache@1: {}
- android-build@1: {}
- save-gradle-cache@1: {}

⚙️ Configuration

Inputs

Key	Description	Flags	Default
verbose	Enable logging additional information for troubleshooting	required	false

Outputs

There are no outputs defined in this step

🙋 Contributing

We welcome pull requests and issues against this repository.

For pull requests, work on your changes in a forked repository and use the Bitrise CLI to run step tests locally.

Note: this step's end-to-end tests (defined in e2e/bitrise.yml) are working with secrets which are intentionally not stored in this repo. External contributors won't be able to run those tests. Don't worry, if you open a PR with your contribution, we will help with running tests and make sure that they pass.

Learn more about developing steps:

• Create your own step
• Testing your Step

bitrise-step-save-gradle-cache's Issues

Can't segregate cache entries per Workflow definition

Troubleshooting

• I've searched discuss.bitrise.io for possible solutions.
• Which version of the step is effected? All versions
• Is the issue reproducible with the latest version? YES
• Does the issue happen sporadically, or every time? EVERY TIME
• Is the issue reproducible locally by following our local debug guide? NOT APPLICABLE

Issue description

Right now, this step computes the same cache key regardless the Gradle task being executed and regardless which Workflow invoked that task for the a given commit hash. This means that in a complex pipeline architecture like :

• Workflow A -> executes unit tests (JVM)
• Workflow B -> builds releaseable artifacts (eg, AAB)
• Workflow C -> runs static analysis (ktlint, detekt, spotless, via Gradle)

under the same trigger, all of them will share the same Gradle cache entry for the same commit hash when applying step-restore-gradle-cache, which might not be the ideal.

For instance, some build tasks related to annotation processors (like kapt) may corrupt cache entries since build outputs are not guaranteed to be stable, which means that we have to invalidate the whole cache for all Workflows despite an offending task corrupting the CI cache belonging to an specific Workflow.

A possible way to improve on such a situation is aggregating information from the Workflow/Job name as part of the cache-key. This is what gradle-build-action does for GHA Jobs, for example.

In this step, this is not the current behavior as per the definition of the key

key = `{{ .OS }}-{{ .Arch }}-gradle-cache-{{ checksum "**/*.gradle*" "**/gradle-wrapper.properties" "**/gradle.properties" "**/gradle/libs.versions.toml" }}`

Hence, I'd love to learn from the team if we could have such a behavior, eventually as opt-in.

A couple of possibilities for a new public API in this step

steps:

# ...

- save-gradle-cache@1:
  inputs:
    segregate-per-workflow: true | false (default)

steps:

# ...

- save-gradle-cache@1:
  inputs:
    cache-hint: none (default) | $BITRISE_TRIGGERED_WORKFLOW_ID  | my-hint

I'm aware we could implement such a behavior with the step-save-cache (and its counterpart) and I'm also aware that such a change must reflect on step-restore-gradle-cache, but since corrupted Gradle caches is a common scenario in large / old Android projects / builds out there, perhaps we can consider this addition.

Gradle Wrapper not cached

Troubleshooting

• I've searched discuss.bitrise.io for possible solutions.
• Which version of the step is effected? 1.1.2
• Is the issue reproducible with the latest version? YES
• Does the issue happen sporadically, or every time? EVERY TIME
• Is the issue reproducible locally by following our local debug guide? NOT APPLICABLE

Issue description

We have a workflow to build our Android app and we recently added the Save/Restore Gradle Cache steps to our workflow. It seems like there is something going wrong because we keep seeing code being recompiled that should have been cached, and we even see the Gradle Wrapper being downloaded every time we execute a build.

We downloaded the cache to inspect the contents, and there is definitely a lot of data cached. We can even see the .gradle/wrapper/ directory and its contents. The logs also show that the cache is downloaded successfully. But somehow the cache is not used correctly.

Bitrise info

• Build URL: https://app.bitrise.io/build/9c4a30ee-6acc-414b-8e81-c31380eb8112
• Bitrise Support enabled: YES

Restore Gradle Cache step looks good:

Input:
- verbose: true
Cache keys:
{{ .OS }}-{{ .Arch }}-gradle-cache-{{ checksum "**/*.gradle*" "**/gradle-wrapper.properties" "gradle.properties" "gradle/libs.versions.toml" }}
{{ .OS }}-{{ .Arch }}-gradle-cache-
Evaluating key template: {{ .OS }}-{{ .Arch }}-gradle-cache-{{ checksum "**/*.gradle*" "**/gradle-wrapper.properties" "gradle.properties" "gradle/libs.versions.toml" }}
Build trigger doesn't have an explicit git commit hash, using the Git Clone Step's output for the .CommitHash template variable (value: d9702225612f9985247ee3eabafbb01529e63afe)
Cache key: linux-amd64-gradle-cache-f2d4ec351f1ef2669ef3ffa9f878d93bcc320e2e6e73cd2fe5f7ae0b7e0047e5
Evaluating key template: {{ .OS }}-{{ .Arch }}-gradle-cache-
Build trigger doesn't have an explicit git commit hash, using the Git Clone Step's output for the .CommitHash template variable (value: d9702225612f9985247ee3eabafbb01529e63afe)
Cache key: linux-amd64-gradle-cache-
Downloading archive...
Exact hit for first key
Archive size: 779MB
Downloaded archive in 4s
Restoring archive...
Restored archive in 3s

Android Build step always downloads the Gradle wrapper:

Downloading https://services.gradle.org/distributions/gradle-8.0.2-bin.zip
...........10%............20%............30%............40%............50%............60%...........70%............80%............90%............100%

Save Gradle Cache step does not save any changes:

Input:
- verbose: true
Cache key: {{ .OS }}-{{ .Arch }}-gradle-cache-{{ checksum "**/*.gradle*" "**/gradle-wrapper.properties" "gradle.properties" "gradle/libs.versions.toml" }}
Cache paths:
~/.gradle/caches/jars-*
~/.gradle/caches/modules-*/files-*
~/.gradle/caches/**/generated-gradle-jars/*.jar
~/.gradle/caches/**/kotlin-dsl
~/.gradle/wrapper
.gradle/configuration-cache
~/.gradle/jdks
Evaluating key template: {{ .OS }}-{{ .Arch }}-gradle-cache-{{ checksum "**/*.gradle*" "**/gradle-wrapper.properties" "gradle.properties" "gradle/libs.versions.toml" }}
Build trigger doesn't have an explicit git commit hash, using the Git Clone Step's output for the .CommitHash template variable (value: d9702225612f9985247ee3eabafbb01529e63afe)
Cache key: linux-amd64-gradle-cache-f2d4ec351f1ef2669ef3ffa9f878d93bcc320e2e6e73cd2fe5f7ae0b7e0047e5
Cache path doesn't exist: .gradle/configuration-cache
Cache save can be skipped, reason: a cache with the same key was restored in the workflow, new cache would have the same content

Steps to reproduce

1. Restore Gradle Cache step
2. Android Build step with standard Android project
3. Save Gradle Cache step

Different cache keys for save & restore steps when using Gradle's precompiled script plugins

Troubleshooting

• I've searched discuss.bitrise.io for possible solutions.
• Which version of the step is effected? 1.1.4
• Is the issue reproducible with the latest version? YES
• Does the issue happen sporadically, or every time? EVERY TIME
• Is the issue reproducible locally by following our local debug guide? YES

Useful information

• FAQ
• devcenter.bitrise.io

Issue description

Our project is using Gradle's precompiled script plugins and it looks like cache keys for restore & save build steps differ.

The restore step's checksum is e1387f while save step's is 7e9d0b. Upon analysis, it looks like there is one additional file included in calculation of save step's checksum: buildlogic/build/kotlin-dsl/plugins-blocks/extracted/***.gradle.kts - this file is not present in VCS, probably is generated during compilation and should otherwise not be taken into account for checksum calculation.

However, it seems that including the original file buildlogic/src/main/kotlin/***.gradle.kts is correct, since that file's configuration could change the state of the cache.

The key template in use is the default one: {{ .OS }}-{{ .Arch }}-gradle-cache-{{ checksum "**/*.gradle*" "**/gradle-wrapper.properties" "gradle.properties" "gradle/libs.versions.toml" }}.

Bitrise info

• Build URL: https://app.bitrise.io/build/217a05f1-065c-466f-9063-1db000fa16b7
• Bitrise Support enabled: YES

Cache isn't updated when adding new cache paths

Troubleshooting

• I've searched discuss.bitrise.io for possible solutions.
• Which version of the step is effected? main
• Is the issue reproducible with the latest version? YES
• Does the issue happen sporadically, or every time? EVERY TIME
• Is the issue reproducible locally by following our local debug guide? NOT APPLICABLE

Useful information

• FAQ
• devcenter.bitrise.io

Issue description

I was trying to test the change that @liamnichols provided in #11 to see if it helped resolve some build slowdown that I was seeing.

It did, which was great! But I nearly didn't notice this because this step doesn't update the cache when paths are changed, and it's necessary to manually delete the cache from the Bitrise UI before the saved cache is updated.

I think this is because the cache key is completely independent of the paths included in the cache paths.

My naive expectation would be that when the cache paths get updated, the stored cache would also be updated.

Bitrise info

• Build URL: Please share the build URL with us.
• Bitrise Support enabled: NO
• Log:

Input:
- verbose: false
Cache key: {{ .OS }}-{{ .Arch }}-gradle-cache-{{ checksum "**/*.gradle*" "**/gradle-wrapper.properties" "gradle.properties" "gradle/libs.versions.toml" }}
Cache paths:
~/.gradle/caches/jars-*
~/.gradle/caches/modules-*/files-*
~/.gradle/caches/modules-*/metadata-*
~/.gradle/caches/**/generated-gradle-jars/*.jar
~/.gradle/caches/**/kotlin-dsl
~/.gradle/wrapper
.gradle/configuration-cache
~/.gradle/jdks
Evaluating key template: {{ .OS }}-{{ .Arch }}-gradle-cache-{{ checksum "**/*.gradle*" "**/gradle-wrapper.properties" "gradle.properties" "gradle/libs.versions.toml" }}
Build trigger doesn't have an explicit git commit hash, using the Git Clone Step's output for the .CommitHash template variable (value: 28a930656d402b20a889e96c0c32b33d0f95d5f2)
Cache key: linux-amd64-gradle-cache-babc08d1de4d839747bdf8969d5880296e0217d6a8ca9ee43b641e90eefaddf2
Cache path doesn't exist: .gradle/configuration-cache
Cache save can be skipped, reason: a cache with the same key was restored in the workflow, new cache would have the same content
  

Steps to reproduce

1. Configure a project using [email protected]
2. Run, and ensure Bitrise saves a cache copy
3. Update to save-gradle-cache@main (or, presumably, 1.1.4 once this is released)
4. Run the build again

What I expect to happen

• Saved cache includes data at the new path

What actually happens

• Cache is unchanged.