Seth Vargo

> - try an archive without compression As far as I know, only tarballs are available for download: https://cloud.google.com/sdk/docs/install > - provide an extracted copy of the archive, where each...

I'm not sure how to help here. I pulled a couple examples from https://github.com/search?q=%22google-github-actions%2Fsetup-gcloud%40v2%22+path%3A**%2F*.yaml&type=code and looked at recent GitHub Actions runs for setup-gcloud, and they are all consistently ~16s: -...

I'm not sure I understand what you mean by "use the github cache from within the official setup-gcloud action"?

I might be mistaken, but that's not something we have control over? Tool caches are not shared between invocations on GitHub-managed runners.

> From what I can tell, setup-cloud-sdk populates the toolCache in installGcloudSdk: https://github.com/google-github-actions/setup-cloud-sdk/blob/370c0eedea4542439152ecedc93bb3ae3e41c0f3/src/index.ts#L183-L188 > > It additionally contains a method -- isInstalled -- to consult the toolCache for a previously...

Is it only cache-missing when the version is "latest"? I'm trying to understand why pre-computing the version is causing a cache hit.

Hmm - then how does the bash script help?

Hmm something super weird is going on then. Is it the call to actions/cache that's actually speeding things up?

Okay I did some digging and benchmarking. I learned a few things: 1. `actions/toolkit/tool-cache` doesn't _actually_ cache things outside of the runner. It's a local cache, not a saved cache...

There's a new option `skip_tool_cache`. For backwards-compat, it defaults to `false`. Setting it to true will dramatically improve installation times, and that will be the default in the next major...