How is the caching logic supposed to work the first time you use this action?

[tstirrat15]

If you've got cache defined, it starts by attempting to restore the cache. If the cache doesn't exist (such as on your first usage of cache), it errors out. Am I missing something?

[tstirrat15]

Possibly related to #329

[tstirrat15]

Never mind - not an issue.

For people coming after me, this differs from setup-ruby (and presumably from other setup actions) in that it doesn't automatically do the install for you, and it does the cache setting as a post-run hook instead of as a part of the setup step.

For the maintainers: can this be called out in the documentation? This wasn't clear or intuitive.

[markgoho]

@tstirrat15 for folks who've previously set up caching node modules via actions/cache this is exactly how that worked

you're comparing this to another runtime/action and expecting it to work the same and then asking the maintainers to update documentation to suit that expectation

why would we add documentation that says "if you're familiar with some other runtime and the way it caches dependencies, this is different!"

[tstirrat15]

Because other CI providers present a unified interface for installing and caching packages?

It's not an unreasonable expectation, coming from another CI provider, to expect Github's CI provider to behave similarly.

[markgoho]

you made the comparison between how the Node.js action caches dependencies and how the Ruby action caches dependencies and now you're comparing GitHub Actions to CircleCI and Jenkins

would you like to keep moving the goalposts? maybe we should next make comparisons between git and subversion?