Closed eskatos closed 4 years ago
Another option until there's a @actions/cache
library would be to leverage @actions/tool-cache
.
A first step has been implemented in #19
The action will now automatically cache the wrapper installation, saving some time downloading and unpacking the Gradle distribution.
It seems like #19 has broken my GitHub Actions builds. I'm yet to figure out why, but can you can explain how I can use a previous version in my GitHub Actions so I get my builds working again? It seems like you're overwritten the version (v1) with this change and I can't use a previous version.
You can see my broken build here: https://github.com/badsyntax/vscode-gradle/runs/769514688?check_suite_focus=true
Firstly, I'm now seeing:
(node:3000) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
Secondly, I'm seeing:
##[error]The "path" argument must be of type string. Received type undefined
The scenario is the first gradle build happens on linux and the second (failing) build happens on windows.
Ooops, I'll look into that, thanks for the report.
You can specify v1.1.0
to use the previous version.
v1
is a dynamic GitHub Action version
Thanks 👍 v1.1.0
is working for me.
Not familiar with the dynamic versioning. This is why I thought I couldn't use a previous version (from https://github.com/marketplace/actions/gradle-command):
I guess that's referring to the dynamic versioning. It's somewhat confusing.
Fixed in v1.2.1
in https://github.com/eskatos/gradle-command-action/commit/c839ac993c41befbe443ddba91a8aafbb5d1f2fb to which v1
points now.
Good point about the version listing on the marketplace. I'll look into publishing each version so it's more clear.
Done
I didn't publish v1.2.0
given it is broken on Windows.
Awesome thanks for this.
I can confirm v1
fixes things for me, and I will continue to use dynamic v1
unless things break again. Great that it's now obvious how to use a previous version.
I can confirm v1
fixes things for me, and I will continue to use dynamic v1
unless things break again. Great that it's now obvious how to use a previous version.
v1.3.0
introduces caching of downloaded dependencies, disabled by default.
Enabling it by default will be #21
Closing as implemented
hey @eskatos i'm getting the following error with v1.2.1
& v1.3.0
:
Build here: https://github.com/badsyntax/vscode-gradle/runs/773519328?check_suite_focus=true
It's odd because I only recently started getting this error. (Yesterday everything was fine using v1.2.1
.)
I don't get this error with v1.1.0
.
Thanks for the report @badsyntax.
It's odd that it happened only Today, I did not change wrapper caching in v1.3.0.
I just published v1.3.1
with an attempt at fixing your issue.
I need to invest more time in integration testing github actions to prevent that to happen again.
IIUC, this happens on Windows when running several Gradle steps without --no-daemon
in a given job. The daemon holds jar files from the distribution open and overwriting them fails on windows. The fix is to not try to restore the cached wrapper if it's already there. It's a good fix anyway.
Thanks for the quick fix. I've verified v1.3.1
works 👍
Indeed i'm running the builds without --no-daemon
as i'm running different builds (using the same gradle version) in multiple steps. Seems like there's benefit to using the daemon in this scenario, but happy to disable the daemon if you reckon there's no benefit in doing so.
It's good to use the daemon when you run several builds in a row. You might want to add an extra step to shut it down at the end (gradle --stop
) otherwise dependencies caching won't work on Windows agents because the cache lock files are held by the daemon.
If you don't you should see something like:
Note that the above only applies if you enable the new caching of dependencies with dependencies-cache-enabled: true
Cool, will do, thanks.
Github Actions agents are ephemeral, Gradle builds need to download the Gradle distribution, generate API jars, download dependencies etc... All this could be avoided on repeated builds by caching the relevant Gradle caches.
One can use https://github.com/marketplace/actions/cache Today but it requires some boilerplate:
This issue is about reusing
actions/cache
mechanism from this very action to reduce that boilerplate.Blocked on https://github.com/actions/cache/issues/55