Feature request: Support built-in cache

[qsliu2017]

I always use actions/cache to cache the default location for cache data, and I think this should be a built-in feature of this action, like setup-node supports dependency caching.

[sebastianst]

That'd be awesome. For reference, actions/cache recommends the following step in your job for Go repos (Linux):

- uses: actions/cache@v2
  with:
    path: |
      ~/.cache/go-build
      ~/go/pkg/mod
    key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}
    restore-keys: |
      ${{ runner.os }}-go-

A nice start would be to mention this actions/cache setup in the README.

[nc-dirknilius]

It's a bit sad as this is the only setup action we use without build-in cache support. setup-node already mentioned, in addition see

https://github.com/marketplace/actions/setup-java-jdk#caching-packages-dependencies https://github.com/marketplace/actions/setup-ruby-jruby-and-truffleruby#caching-bundle-install-automatically
https://github.com/marketplace/actions/setup-python#caching-packages-dependencies

[dmitry-shibanov]

Hello everyone. We released the new version of setup-go with caching support and updated major tag. For now I'm going to close the issue if you have any concerns feel free to ping us.

[lucacome]

Hello, I replaced

- uses: actions/cache@v2
  with:
    path: |
      ~/.cache/go-build
      ~/go/pkg/mod
    key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}
    restore-keys: |
      ${{ runner.os }}-go-

with the built-in cache, but seems like it's not achieving the same result, as the build time is up to 3-4 minutes form ~40s-1m.

I suspect this is because it needs to download the modules instead of using the cached ones, any ideas?

EDIT: It might be because I have the setup in different jobs, but the key is always the same, so the cache is not updated? I used to have different keys, for like the unit tests and the build

[e-korolevskii]

Hello @lucacome
Could you please open a separate issue with a detailed description and steps to reproduce it?

[same-id]

Maybe perhaps this is because there are not "restore-keys", only exact match on primary key?

At least this is what I'm trying to understand now