setup-sam
setup-sam copied to clipboard
Use `@actions/tool-cache`
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 wildcard versions? (e.g.
1.*
) Can't cache1.*
otherwise would never update;tool-cache
doesn't seem to provide solution to invalidate. Would at minimum have to find version installed; anything notpip
seems fragile.
I think this is a GREAT idea 💯 If you need any help doing this let me know 👍
Any movement on this? (or is there another avenue for caching?)
@justinwb No major updates just yet, but I've opened https://github.com/aws-actions/setup-sam/pull/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 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?
@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 🎉
@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 https://github.com/aws-actions/setup-sam/issues/64#issuecomment-1368755583 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 https://github.com/aws-actions/setup-sam/issues/64).
@justinwb It looks like (for now, at least) the
with-installer
flag defaults tofalse
. I've changed a handful of my workflows to addwith-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 🙌
With https://github.com/aws-actions/setup-sam/pull/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.
Resolving this in favor of the more granular https://github.com/aws-actions/setup-sam/issues/76 as caching is now supported with use-installer
and version
.