Are downloads cached?

[aviflax]

Hi, I’m interested in using this action, but I can’t tell whether it caches Clojure and whichever tools are specified (in my case it’d be tools.deps along with the CLI tools.) I’m generally uncomfortable with automations that download the same dependencies every time they run, so I personally tend to include very comprehensive caching in my automations (example).

I did search the code and saw that it’s using @actions/tool-cache which seems promising, but when I read the docs I found this:

Finally, you can cache these directories in our tool-cache. This is useful if you want to switch back and forth between versions of a tool, or save a tool between runs for self-hosted runners.

(emphasis mine)

This seems to imply that @actions/tool-cache does not actually, you know, cache anything, when running on GitHub’s runners. But of course, there’s a very good chance I’m just missing something here.

Bottom line: does this action currently its downloads when running on GitHub’s runners?

Thank you!

[rymndhng]

Take this with a grain of salt (since I'm not the maintainer), but I believe it does cache. If you read further down the doc you linked:

You can also cache files for reuse.

const tc = require('@actions/tool-cache');
const cachedPath = await tc.cacheFile('path/to/exe', 'destFileName.exe', 'myExeName', '1.1.0');

Also a cursory look at the code confirms that the functions are used. See https://github.com/DeLaGuardo/setup-clojure/search?q=cacheDir

[pmonks]

GitHub's cache action does this, and is leveraged by the setup-java action for exactly this purpose.

I too am in favour of setup-clojure doing something similar, though in looking through the setup-java action's code to try to see how this might be done (for a PR), I realised I'm way out of my depth when it comes to the specifics of implementing GitHub actions.

[zharinov]

I did some research and can conclude that GitHub action should be widespread enough in order to benefit from tool cache.

Here is the result of ls /opt/hostedtoolcache/ command executed in the action step:

CodeQL
Java_Adopt_jdk
Java_Temurin-Hotspot_jdk
PyPy
Python
Ruby
go
node

It seems like each next run is more likely to be performed in some other random machine. For some reason, I assumed GitHub has mechanism that assigns previously used physical runners when possible, so we often hit the tool cache. Seems like it's not the case.

[zharinov]

If I understand correctly, there is two separate cache concepts for GitHub actions:

• Tools cache (@actions/tool-cache)
  • Stored in the place that can be found from RUNNER_TOOL_CACHE env
  • Reusable between steps, not between jobs (unless the tool is super-popular)
  • Actions have limited control over them on GitHub-hosted runners (see setup-java documentation), but for self-hosted GitHub it can be populated by admin (see GitHub doc).
• Dependency cache (@actions/cache)
  • The actual caching mechanism we mean when talking about CI/CD caching
  • Limited by 10GB storage total and 7 days TTL for unused keys

What we probably want is to leverage the second one to store Java distributions, Clojure tools, .m2 and git-based dependencies as well.

What I want to try is to pre-populate @actions/tool-cache items with previously saved @actions/cache items such that setup-java, setup-graalvm and setup-clojure itself would frequently find their respective tooling.