buehlerjochen
commented
1 month ago @ljacomet I attended your talk about ephemeral CI on Devoxx London and we talked on the way out. Maybe you have an idea about this issue?
Closed buehlerjochen closed 1 month ago
buehlerjochen
commented
1 month ago @ljacomet I attended your talk about ephemeral CI on Devoxx London and we talked on the way out. Maybe you have an idea about this issue?
bigdaz
commented
1 month ago I presume this is a compatibility issue with GHES. I'm aware that some users have had success using setup-gradle with GHES, but I have no way to test this compatibility.
There are a couple of things that you could try to help diagnose this issue:
actions/cache directly to save/restore the Gradle User Home: https://github.com/actions/cache/blob/main/examples.md#java---gradleactions/cache@v4 as well as v3 as described in the above examplesetup-gradle action, which was gradle/gradle-build-action@v2. All input parameters listed in your example should work the same.buehlerjochen
commented
1 month ago @bigdaz Thank you for the quick response.
I'm also afraid it might be a compatibility issue with GHES. But can it be that I am the first to report it?!
Following your suggestions, here is what I tested in order to diagnose the problem:
1) Use basic actions/cache
Save cache works a bit different, but is able to upload the cache:
Post job cleanup.
/usr/bin/tar --posix -cf cache.tgz --exclude cache.tgz -P -C /runner/_work/jira-reports-gradle-plugin/jira-reports-gradle-plugin --files-from manifest.txt -z
Cache Size: ~324 MB (339440983 B)
Cache saved successfully
Cache saved with key: Linux-gradle-95ecf835a01192c137176bcb253c71ee27a6e335f97304a3e86bee887c59dbf3Restore also fails with Failed to restore: Content-Length not found on blob response
This is the full log output:
Run actions/cache@v3
with:
path: ~/.gradle/caches
~/.gradle/wrapper
key: Linux-gradle-95ecf835a01192c137176bcb253c71ee27a6e335f97304a3e86bee887c59dbf3
restore-keys: Linux-gradle-
enableCrossOsArchive: false
fail-on-cache-miss: false
lookup-only: false
env:
JAVA_HOME: /opt/hostedtoolcache/Java_Zulu_jdk/17.0.11-9/x64
JAVA_HOME_17_X64: /opt/hostedtoolcache/Java_Zulu_jdk/17.0.11-9/x64
Warning: Failed to restore: Content-Length not found on blob response
Cache not found for input keys: Linux-gradle-95ecf835a01192c137176bcb253c71ee27a6e335f97304a3e86bee887c59dbf3, Linux-gradle-2) Try actions/cache@v4 as well as v3
Exactly the same result as with v3.
3) Use gradle/gradle-build-action@v2
Cache upload works as before.
Restore fails with the same error as with setup-gradle@v3:
Entry: Gradle User Home
Requested Key : v8-gradle|Linux|build commit-compatibility-test[26be8a9e10540768cab7c84d80a576df]-883739c846e093442084301e65231f046dec42ff
Restored Key :
Size:
(Entry not restored: Content-Length not found on blob response)
Saved Key :
Size:
(Entry not saved: cache is read-only)4) Run setup-gradle action with debug output
I thought this might help you with diagnosing the problem.
bigdaz
commented
1 month ago The setup-gradle action is using the actions/cache library under the covers. So if actions/cache@v3 is not able to work in your environment, then there's nothing we can do so resolve the issue with setup-gradle.
Folks are using GHES successfully with setup-gradle, so I suspect the issue is with your particular installation. I don't really know how GHES is installed and configured, but I can imagine that a some internal network infrastructure could be blocking the response, or stripping the content-length header from the response.
buehlerjochen
commented
1 month ago Yes, that is what I suspect as well. I already reached out to our operations team to clarify the issue. Thank you for your help and analysis. ♥️
Hi,
I would like to use the
setup-gradleaction to store and restore the Gradle caches. But the action fails every time due to errors like this:Warning: Failed to restore gradle-home-v1|Linux|compatibility-test[b2e82155fc439b8351abee85b9386021]-8410f0ac768ab745eaf88d7100791f8a4378a0bd: Error: Content-Length not found on blob responseWe have a build with multiple jobs, the relevant ones are:
These are the jobs (simplified) from the workflow file:
I can see how the action stores the cache for the compile job, but then fails when restoring during:
generate-job-summaryis enabled and I can see how the action stores cache entries in the compile job, but does not restore them in the compatibility test job and in subsequent build executions. For the failed restore attempts, it prints these details:We are using:
Could it be that there is a compatibility issue with GHES? Or am I doing something wrong?