-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in 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: