Add 'cache: true' option to enable caching

[omelkonian]

• Caches output.cabal-store and ./dist-newstyle

• Currently hashFiles is not exposed in the actions/cache API, hence the use of folder-hash.hashElements

[hazelweakly]

I like it so far! If we're going to have a generic cache: true option, it should work for stack as well as cabal out of the box.

For stack, output.stack-root would be what was cached (which I just realized I never properly put inside the action.yml file... sigh).

Then I suppose there's the question of what sort of API to expose to allow people to customize things. Something that will likely be important is doing the minimal amount of work while not being useless about it. (So, for example, running cabal freeze in CI is something I see people do a lot. I don't understand it because it seems to completely defeats the purpose of a freeze file; does this not break repositories where freeze files are checked in?).

I'll comment on the PR with a few more specific thoughts. Thanks for doing a lot of work on this!

[larskuhtz]

(So, for example, running cabal freeze in CI is something I see people do a lot. I don't understand it because it seems to completely defeats the purpose of a freeze file; does this not break repositories where freeze files are checked in?).

One reason to run cabal freeze in CI is to include the freeze file in the artifacts for reproducible builds and documentation purposes. So, one builds and tests against the most recent versions from Hackage, but one can roll back to the latest working state if something breaks.

[lisanna-dettwyler]

(So, for example, running cabal freeze in CI is something I see people do a lot. I don't understand it because it seems to completely defeats the purpose of a freeze file; does this not break repositories where freeze files are checked in?).

One reason to run cabal freeze in CI is to include the freeze file in the artifacts for reproducible builds and documentation purposes. So, one builds and tests against the most recent versions from Hackage, but one can roll back to the latest working state if something breaks.

@larskuhtz That does sound really useful! It could also allow for freeze files to not be used by default unless the build fails, then it's retried with the last known good one. If it's a pull request it could offer to update the file in the branch too if building from a fresh one works. And it's easy to check if there's a freeze file present already and not mess with it.