Allow users to specify download directory for IDEs to make use of GitHub Caching

[ChrisCarini]

From @YannCebron on JetBrains Platform Slack:

one thing I’d like to see, is ability to specify download directory for specified IDEs so one can use caching to avoid redownloading GB’s of IDE distributions on each run

CC: @hsz

[ChrisCarini]

GH's v2 @actions/cache NPM package may make this better in typescript land: https://github.blog/changelog/2020-05-27-github-actions-v2-cache-actions/

[filiphr]

Wouldn't it be better to use the GitHub tool-cache for this?

[ChrisCarini]

Hi @filiphr ! Thank you for sharing this, I had not seen it before! Based on a quick look, I believe using tool-cache would require this GH action to be written in JS/TS. This is something that I actually started on a while ago and just haven't had time to clean up. Once I pick that back up, I will certainly try to incorporate tool-cache - one of the slowest parts of this action is downloading the IDEs, especially if there are several specified.

Thank you, again, for pointing this out and making me aware of tool-cache, this seems very promising!

[ChrisCarini]

@actions/tool-cache

Some inspiration for how this might be able to be accomplished using @actions/tool-cache:

• https://github.com/dapr/setup-dapr/blob/45e34f2700204c42cca901d955b20f22fef8200e/action.js#L37
• https://github.com/bufbuild/buf-setup-action/blob/abf079cff7cba30a0cfffda3b302fccfc061e3b0/src/buf.ts#L27

I could possibly convert this action into a composite action, and have several individual actions for:

1. Downloading plugin verifier - leverage @actions/tool-cache
2. Downloading N versions of JetBrains IDEs - leverage @actions/tool-cache
3. Iteratively running the verifier against N versions of IDEs

HOWEVER, looking into this more, it seems that @actions/tool-cache simply caches whatever tool on the runner it's being executed on. Once that runner is cleaned up (which, is after the completion of each individual 'job'; see below), the tool that was downloaded is gone.

When the job begins, GitHub automatically provisions a new VM for that job. All steps in the job execute on the VM, allowing the steps in that job to share information using the runner's filesystem. You can run workflows directly on the VM or in a Docker container. When the job has finished, the VM is automatically decommissioned.

ref: Using a GitHub-hosted runner

That's to say, @actions/tool-cache would be useful if we had logic that, for example, needed to download+use a given version of a tool multiple times - specifically, the 'download' portion, as 'use' is a minimal cost as it would already exist on the runner file system.

This might be more useful if we were able to have a step that downloaded the verifier + IDE(s) for use in both this GitHub action, but were also able to be leveraged by the various gradle tasks that need each tool.

@actions/cache

The @actions/cache lib (and, action) DO actually allow persisting a cache across workflows/jobs, however it is not a 'global' cache across all GitHub repos (details below). Ideally, there would be a way to download+cache a new version of plugin verifier (or, IDE(s)) so that any repo on GitHub can automatically pull from the cache, however it seems like this might be a desired limitation to address possible security concerns (See actions/cache#79 (comment) for some details).

Perhaps we could leverage the resolution strategy of key and restore-keys in @actions/cache on a per (a) verifier+version and (b) IDE+version basis; screenshot of an example from the docs below:

HOWEVER, the per-repo total cache size is 10GB:

GitHub will remove any cache entries that have not been accessed in over 7 days. There is no limit on the number of caches you can store, but the total size of all caches in a repository is limited to 10 GB.

ref: Usage limits and eviction policy

This might be a limiting factor / make the caches (again, not just the IDE/verifier cache, but any cache in the repo) get evicted more frequently, as the current archives of IDEA (version 2024.1.2) are ~1.2GB - should we cache these in the action, it could potentially cause other caches in the repo to get evicted earlier than desired. Maybe a setting to enable/disable caching could be exposed from this action.

[ChrisCarini]

Oh, also worth noting, for the verifier, because it is simply a *.jar file, the Cross OS cache could be used to cache that tool across all the OSs that might have the verifier run against.