Support caching

[hoffa]

With #15 merged, at every run all files are stored under a new random temporary directory.

We could use @actions/tool-cache to avoid downloading SAM CLI each time. Only really useful for self-hosted runners as they don't have a fresh machine each time.

Questions:

• Does the symlink cache without issues? https://docs.python.org/3/library/venv.html#creating-virtual-environments "While symlinks are supported on Windows, they are not recommended."
• What about actions/cache? Caches directory as key; needs to know directory; used for caching across runners.
• What about @actions/cache?
• What about wildcard versions? (e.g. 1.*) Can't cache 1.* otherwise would never update; tool-cache doesn't seem to provide solution to invalidate. Would at minimum have to find version installed; anything not pip seems fragile.

[NickLiffen]

I think this is a GREAT idea 💯 If you need any help doing this let me know 👍

[justinwb]

Any movement on this? (or is there another avenue for caching?)

[hoffa]

@justinwb No major updates just yet, but I've opened #70, which adds support for using the native installers (i.e. without needing Python separately, or pip), making installs a lot faster, and should make caching easier as well.

[justinwb]

@justinwb No major updates just yet, but I've opened #70, which adds support for using the native installers (i.e. without needing Python separately, or pip), making installs a lot faster, and should make caching easier as well.

Great - thanks for the quick response. Anything we need to do to take advantage of this (looks like #70 was just merged) or should we expect to see it come downstream soon in latest setup-sam?

[aidansteele]

@justinwb It looks like (for now, at least) the with-installer flag defaults to false. I've changed a handful of my workflows to add with-installer: true and they've all dropped from 28-35s (before) to 3s (after). This change has made my day 🎉

[hoffa]

@justinwb No major updates just yet, but I've opened #70, which adds support for using the native installers (i.e. without needing Python separately, or pip), making installs a lot faster, and should make caching easier as well.

Great - thanks for the quick response. Anything we need to do to take advantage of this (looks like #70 was just merged) or should we expect to see it come downstream soon in latest setup-sam?

You can use it right now in v2 for Linux x86-64:

- uses: aws-actions/setup-sam@v2
  with:
    use-installer: true

And you can get rid of setup-python if you only use it for setup-sam.

As @aidansteele mentioned it's disabled by default. We can't easily enable by default in v2 due to backward compatibility; native installers only support certain platforms, old SAM CLI versions did not include any native installers, and some people might be using hacks such as #64 (comment) that depend on the old approach. We'll probably enable it by default in a future v3, and drop the pip approach from setup-sam altogether (it's slow and causes occasional issues with transient dependencies such as #64).

[justinwb]

@justinwb It looks like (for now, at least) the with-installer flag defaults to false. I've changed a handful of my workflows to add with-installer: true and they've all dropped from 28-35s (before) to 3s (after). This change has made my day 🎉

Seeing the same - has dropped down to 2-3s on average 🙌

[hoffa]

With #73 merged, if you have use-installer: true and specify the version, it'll cache the SAM CLI for future use. This is beneficial for self-hosted runners. It doesn't currently cache when version is not specified.

[hoffa]

Resolving this in favor of the more granular #76 as caching is now supported with use-installer and version.