Gradle state from cache not restored from tags about actions

[joschi]

This might be related to actions/cache#1361.

[bigdaz]

Thanks for your report.

What you're seeing is the result of access restrictions applied by GitHub Actions on cache entries. Read here for the details, but note in particular that Workflow runs also cannot restore caches created for different tag names.
There is more context in the setup-gradle docs.

You said:

The action apparently only tries to download gradle-home-v1|Linux|test-product-components[5d434b537dd905dcf51d5f2bd5e8022e]-7fb4e5a6a4f5a839b7a360204248ab6117a28e15 which fails but never tries the other restore keys (which would succeed)

This is incorrect. You can see from the logs that the action actually passes all of the keys including the restore keys in it's request.

This logging comes from the action:

  Requesting Gradle User Home with
      key:gradle-home-v1|Linux|test-product-components[5d434b537dd905dcf51d5f2bd5e8022e]-7fb4e5a6a4f5a839b7a360204248ab6117a28e15
      restoreKeys:[gradle-home-v1|Linux|test-product-components[5d434b537dd905dcf51d5f2bd5e8022e],gradle-home-v1|Linux|test-product-components,gradle-home-v1|Linux]

This logging comes from the GitHub Actions caching infrastructure:

  ##[debug]Resolved Keys:
  ##[debug]["gradle-home-v1|Linux|test-product-components[5d434b537dd905dcf51d5f2bd5e8022e]-7fb4e5a6a4f5a839b7a360204248ab6117a28e15","gradle-home-v1|Linux|test-product-components[5d434b537dd905dcf51d5f2bd5e8022e]","gradle-home-v1|Linux|test-product-components","gradle-home-v1|Linux"]

In both cases, you can see that the restore keys are being passed. As explained, the cache misses are due to cache access restrictions, not due to the incorrect keys being used.

The setup-gradle action has no control over these access restrictions or over the branch/tag that is bound to a cache entry.

[joschi]

@bigdaz Thanks for the explanation! Too bad it doesn't work in our setup, but I see why now. 😄