Use GitHub Actions cache for installed binaries

[flip1995]

Fixes #4

This uses the changes from actions-rs/core#92 to install

For easier review, I'll comment some of the code changes.

This is the first time I'm writing TS code ever, so I'm not confident that this is the right way to do it. I think, after merging actions-rs/core#92, I have to rebuild and commit dist/index.js?

This change has to be merged together with/after actions-rs/core#92

Drawbacks

This removes the use-cache key, since with this implementation it is useless. I wouldn't consider this breaking change a problem though, since this is an experimental action and this key was unused anyway.

[Blisto91]

Do i understand it correctly that this would work with any crate installed through actions-rs/install and not just specific precompiled binaries like it is currently?

[flip1995]

@Blisto91 exactly. It will cache every binary in a cache named <binary-name>-<key>, if you provide a key (like in the actions/cache action)

You can still fall back to actions-rs/tool-cache if you want, though. This is useful for 2 reasons:

1. backwards compat for the use-tool-cache key
2. You don't have to cache the binary yourself, if it is in the tool-cache action.

[Blisto91]

@flip1995 Sounds awesome!

Hope it gets merged soon :).

[svartalf]

@flip1995 I published new actions-rs/core version with your changes in it (should be 0.1.4), can you update your PR?

[flip1995]

@svartalf did something during publishing go wrong?

src/download.ts:5:10 - error TS2305: Module '"../node_modules/@actions-rs/core/dist/core"' has no exported member 'resolveVersion'.

5 import { resolveVersion } from "@actions-rs/core";
           ~~~~~~~~~~~~~~

src/input.ts:21:31 - error TS2339: Property 'getInputAsArray' does not exist on type 'typeof import("/home/runner/work/install/install/node_modules/@actions-rs/core/dist/input")'.

21     const restoreKeys = input.getInputAsArray("restore-keys") || undefined;
                                 ~~~~~~~~~~~~~~~

src/main.ts:59:13 - error TS2554: Expected 1-2 arguments, but got 4.

59             options.primaryKey,
               ~~~~~~~~~~~~~~~~~~~
60             options.restoreKeys
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

all of this should be in the new release 🤔

[svartalf]

@flip1995 ah yes, sorry, that was an incorrect release indeed. Just published 0.1.5, can you try that one?

[flip1995]

@svartalf CI looks good 👍

[svartalf]

I don't think it is a good idea to force users to provide all necessary cache keys, as Action can do that by itself; grab the crate name, version and current runner name (ex. ubuntu-18.04), join them together - we got a cache key.
That also mean that we will need to use resolveVersion if there is no version specifically set in the Action arguments or set to "latest", for example.

Ideally, from the user side I would expect to write

- uses: actions-rs/install@v0.2
  with:
    crate: cargo-make

and it will handle all the stuff by itself.

[flip1995]

My thought behind adding those keys was that there is currently no way to force-update a cache. If a new cache should be created, the cache has to get a new name. With actions/cache in rust projects, this is for example done by hashing the Cargo.lock files.

But when caching binaries I guess only naming the hash with the version number should do the trick. There should be no need to add a hash to the cache name.

Should I remove the keys completely or should I just make them optional?

---

The part with resolving the version is already implemented. But I still have to add the runner name.

[flip1995]

@svartalf Do you have a suggestion how I might get the name of the runner? I looked at the @actions/github and @actions/core package, but couldn't find any functions with which I'm able to access the runner name.

If we're able to get the runner name $somehow, we can get rid of the key/restoreKeys arguments of the action and go back to useCache. This change has to be implemented in actions-rs/core though.

[flip1995]

@svartalf I removed the key arguments from the action again and introduced the old useCache argument. This requires the changes in actions-rs/core#125 though. I'm not sure how to the the name of the current runner, it would be great if you could help me with that.

[svartalf]

@flip1995 I don't think there is any reliable and already existing way to do that, our best shot would be to use combination of process.platform and os.version probably; latter one should handle the different Ubuntu versions provided by Github.

[flip1995]

@svartalf In actions-rs/core#125 I use a combination of os.platform() + '-' + os.release() + '-' + os.arch(); to determine the runner. Should I change os.release to os.version()? os.platform() is the same as process.platform IIUC.

[svartalf]

@flip1995 yeah, os.release() seems to be more precise, let's use it!

[flip1995]

@svartalf Can you take another look at actions-rs/core#125 in combination with 57e52b9 then, please?

[coltfred]

Has there been further development on this? With the old tool-cache repo not updating with new binaries it's very painful.

[flip1995]

This is still waiting on review of actions-rs/core#125 which then will require an update of 57e52b9

[FlorianFranzen]

So am I getting this right? Even though core supports cached installs for over 2 years, it has not made it into the install action, because we want core also to run os.platform() + '-' + os.release() + '-' + os.arch() for us, instead of just running it in the install action?

[flip1995]

To do this cleanly without backwards breaking changes, yes a the actions-rs/core#125 PR has to be merged.

The alternative would be to merge this with a breaking change, just to revert the breaking change when doing this cleanly, which again would be a breaking change.

[thomaseizinger]

I just came across https://github.com/ryankurte/cargo-binstall which might be useful for other people interested in this feature.