Skip to content

Version in tool cache is often behind go-versions manifest's latest #73

@bdd

Description

@bdd

Goal: Set minimum required Go version but pick the latest available

For the use case of specifying a lower bound Go version for a project but defaulting to the latest release I'm using this action config fragment:

      - uses: actions/setup-go@v2
        with:
          go-version: '>=1.5 <2'

Down the rabbit hole 🐇

Check tool-cache

setup-go first checks if a matching version Go is in the tool cache. https://github.com/actions/setup-go/blob/main/src/installer.ts#L41

With ACTIONS_STEP_DEBUG=true, the relevant part from a build run:

Setup go stable version spec >=1.5 <2
##[debug]isExplicit: 
##[debug]explicit? false
##[debug]isExplicit: 1.11.13
##[debug]explicit? true
##[debug]isExplicit: 1.12.17
##[debug]explicit? true
##[debug]isExplicit: 1.13.15
##[debug]explicit? true
##[debug]isExplicit: 1.14.7
##[debug]explicit? true
##[debug]isExplicit: 1.15.0
##[debug]explicit? true
##[debug]evaluating 5 versions
##[debug]matched: 1.15.0
##[debug]checking cache: /opt/hostedtoolcache/go/1.15.0/x64
##[debug]Found tool in cache go 1.15.0 x64
Found in cache @ /opt/hostedtoolcache/go/1.15.0/x64

(Although the debug looks like it's iterating from oldest version in cache, it actually isn't the behavior. These are _isExplicitVersion(...) calls from findAllVersions() in @actions/toolkit/.../tool-cache.ts
https://github.com/actions/toolkit/blob/master/packages/tool-cache/src/tool-cache.ts#L514)

GitHub local Go Versions Manifest

Only if there isn't a matching version in the cache, it proceeds to checking @actions/go-versions:versions-manifest.json. A file that seems to be periodically generated, approved by humans in a PR, and gets committed again by a bot.

If we check versions-manifest.json, it has Go 1.15.1 in it. On the other hand the cache only has—semver cleaned up—1.15.0.

Can we prime the cache?

To debug this, I tried priming the cache by hardcoding the version and seeing if installGoVersion() from installer.ts would actually put this into the cache.

It says so:

##[debug]Caching tool go 1.15.1 x64
##[debug]source dir: /home/runner/work/_temp/9b74f02e-5739-4ef8-8416-f3c2b222710b
##[debug]destination /opt/hostedtoolcache/go/1.15.1/x64
##[debug]finished caching tool

...but when I revert back to >=1.5 <2 version spec and run the action again, it continues to match 1.5.0 from the tool-cache.

Questions

How does /opt/hostedtoolcache get populated?

Seems like only PyPy, Python, Ruby, boost, go, and node are the tools in this directory.
Makes me think this is centrally curated, and not a globally shared cache.

What cache gets updated by installGoVersion()?

When it calls tc.cacheDir on the extracted Go install, what is the effective cache domain for this? Is it global, per project, per user, per run?

Is checking the cache with a version spec intentional?

If we don't have an explicit version, setup-go checks the cache with the supplied semver version spec. Is this intentional? Because of this, there's no way to provide a version spec but hope to expect to get the latest version in go-versions manifest file, or directly from Google.

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