Stop fetching caches if it takes a lot of time

[JavierSegoviaCordoba]

GitHub Actions Cache can have issues where it takes almost forever to download them.

I think if after some time, the fetching is still running, Gradle should start to run even without reusing caches and stop trying to finish fetching caches. The previous cache shouldn't be discarded.

Run: https://github.com/JavierSegoviaCordoba/compose-resources-kmp/runs/7390287447

[bigdaz]

There's clearly an issue with actions/cache that is causing this.
It would be great if we could cancel the cache-restore on a configurable timeout, and continue with the rest of the action. However, there's no obvious way to do this with the @actions/cache API, so I think we'd need to implement something and ensure that we could effectively abort the cache restore (if the restore continued while Gradle was executing I can see this being problematic).

Ideally, the @actions/cache API would provide an options to set the overall timeout. There's DownloadOptions.timeoutInMs, but the default value of 30s is clearly not applying to the overall restore operation. I suspect this setting is the timeout for each 4Mb block.

[bigdaz]

@JavierSegoviaCordoba I've spiked a solution to this issue in this commit. The timeout is currently not configurable and is hard-coded to 2 minutes.

I haven't tested this extensively, but it would be great if you could test it out with your project. In case of a cache restore timeout you'll see an extra warning in the GitHub Actions console as well as in the caching summary rendered in the Job Summary window.

To test this out, simply reference the (unreleased) version as: gradle/gradle-build-action@dd/cache-timeout.

[JavierSegoviaCordoba]

@bigdaz the problem about testing this is not depending on me, it is more about the state of GitHub actions cache.

Maybe I can see this issue multiple times on the same day that I can't see it for months, so I can put that commit but not being able to check if it works in an undetermined time.

[bigdaz]

Understood. I'll do some local testing with a shorter timeout value, but I'm really interested in how it copes with the real-world case of a cache-restore that hangs.

If you are able to switch to that branch version I'd appreciate it. I'll keep it rebased on the latest patch release of the action.

[trask]

@bigdaz I was able to still get the issue using gradle/gradle-build-action@dd/cache-timeout, check out https://github.com/open-telemetry/opentelemetry-java-instrumentation/runs/7402392291?check_suite_focus=true

[bigdaz]

@trask Thanks for testing. I'll continue to investigate.

[bigdaz]

This issue has been reported as fixed in the @actions/cache library v3.0.3: actions/cache#810.
The timeout currently defaults to 1hr, but I will endeavour to configure a shorter timeout.

[JavierSegoviaCordoba]

Yeah I read it and I thought that 1h timeout has no sense as default value...

[kotewar]

Hi @bigdaz, @JavierSegoviaCordoba 👋🏽

I am from the @actions/cache team and we are working on giving user more control on the timeout part where you could configure the timeout in the action and not wait for an hour. The 1 hour timeout was introduced as we hadn't heard back from the Azure team on the SDK changes that were required for fixing the problem.

[JavierSegoviaCordoba]

@kotewar thank you for the explanation 🙂

[bigdaz]

Hi @kotewar @JavierSegoviaCordoba : From my understanding the timeout configuration is already available in the @actions/cache library, as opposed to the action. Here is where the gradle-build-action is overriding the default 1hr timeout with a configurable timeout:

gradle-build-action/src/cache-utils.ts

Lines 156 to 158 in 8f9b7c7

	const restoredEntry = await cache.restoreCache(cachePath, cacheKey, cacheRestoreKeys, {
	segmentTimeoutInMs: getCacheReadTimeoutMs()
	})