-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Cache cleanup fails with "Unable to locate executable file: gradle" when Gradle is not pre-installed on runner #33
Comments
ok, for these who are having the same issue the workaround is the following
so Having said that the issue is that |
This seems like a bug to me. Isn't the whole point of using the Wrapper version that you don't have to worry about per-project Gradle versions? 🤔 |
IssueThanks for the report. I tested this feature on ubuntu-latest, windows-latest and macos-latest runners, all of which have a recent version of Gradle pre-installed. This pre-installed Gradle version is used for the cache-cleanup process. However it appears that ubuntu-22.04 does not come preinstalled with Gradle on the PATH, so the cache-cleanup feature will indeed fail. This is a bug in the action: cache-cleanup should work even if the runner does not have a recent version of Gradle pre-installed. WorkaroundYou can force the action to download and install a recent gradle version by specifying a Note that you can still use the Gradle wrapper to execute your project. Here's a working example:
|
Thanks for the quick response @bigdaz! That's exactly the conclusion we came to too 😄 The problem is that we use a central workflow for all our Gradle projects, so the Gradle version differs from project to project. We can work around this by getting the current WDYT? |
Or, alternatively: Would we just be able to use |
We have a PR up in gradle/gradle-build-action#427. I'm unsure about the state handling here - we can probably clean that up with some guidance on the expected architecture 😄 |
gradle-home-cache-cleanup: true
Do we have an update on this? |
Not really. The current PR is a bit problematic (assumes Gradle project is root of repository), and I'm not sure when we'll have time to address this. There is a simple workaround:
|
I've tried to make another PR, but it seems hard since:
Here is a workaround if you are using only a wrapper and do not want to install standalone Gradle at all (only tested in self-hosted runner provisioned by actions-runner-controller): - name: Set /usr/bin/gradle alias to gradlew # https://github.com/gradle/actions/issues/33
run: sudo ln -s "$GITHUB_WORKSPACE/gradlew" /usr/bin/gradle Thanks to @andersfischernielsen for the base idea! |
Another workaround: (you will need to swap - name: Enable actions/cache for Gradle
uses: gradle/gradle-build-action@a4cf152f482c7ca97ef56ead29bf08bcd953284c # v2.7.0
with:
gradle-home-cache-cleanup: true
- name: Gradle Build
shell: bash
run: |
./gradlew build
echo "$(find /home/.gradle/wrapper/dists/ -name gradle | xargs ls -tr | tail -n 1 | xargs dirname)" >> $GITHUB_PATH |
To cleanup Gradle User Home, a Gradle build must be executed. Newer Gradle versions are able to cleanup the home directories of older versions, but not vice-versa. With this change, the latest version of Gradle is automatically provisioned in order to run Gradle User Home cleanup. This ensures a consistent version of Gradle is used for cleanup, and fixes #33 where Gradle is not pre-installed on a custom runner.
Our gradle action config looks as the following
so assumption is that in post-action gradle will clean up cache in home directory thanks to
gradle-home-cache-cleanup: true
. Actually in Post Setup Gradle I see the following messagebased on sources https://github.com/gradle/gradle-build-action/blob/main/src/cache-cleaner.ts I see as if dummy gradle project does actual clean up. But from where this project should get gradle to execute this
?
Would you please clarify how to properly configure
gradle-home-cache-cleanup
so it would getgradle
from somewhere. Thanks!The text was updated successfully, but these errors were encountered: