Skip to content

Feature request: Support built-in cache #130

Closed

Description

@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.

Activity

  1. sebastianst commented on Feb 17, 2022

    @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.

  2. dmitry-shibanov commented on May 30, 2022

    @dmitry-shibanov
    Contributor

    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.

  3. lucacome commented on Aug 6, 2022

    @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

  4. e-korolevskii commented on Aug 10, 2022

    @e-korolevskii
    Contributor

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

  5. same-id commented on Mar 23, 2023

    @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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestNew feature or request to improve the current logic

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions