Cache readonly

[mbarbin]

• Add a new input to use the cache in a read-only fashion.
• Simplify handling of the README to support ongoing development
• Enable the cache-readonly repo in the CI of this repo when not on the main branch (applicable to PRs).

[mbarbin]

Fixes #23

[shym]

I only had a quick look at it but it looks pretty nice, thank you for that!
Seeing the mostly-duplication of the actions/cache code had me thinking: as we have to duplicate it, might this be an opportunity to really use the separate actions/cache/restore and actions/cache/save and use that to provide the possibility to save the cache even in case of failure (using if: always() && ...). Instead of cache-readonly, maybe we could have a save-cache input ranging over onsuccess, always, and never, say. What do you think?

[mbarbin]

Thank for you having a first look!

To help us support that discussion I pushed another few commits to that exploratory branch if you wanna have a look too:

https://github.com/mbarbin/setup-dune/tree/cache-readonly.exploratory

Re: onsuccess vs always I am not really sure. I have been in that boat of attending a long build (actually last week or something), and then a small error at the end occurs, and the next build will go from scratch.. So I hear you! That being said, with a maintainer hat, I would find it easier if there wasn't many toggles. Maybe we can make an opinionated decision and choose that strategy, and let users delete their caches if they're unhappy?

[mbarbin]

Ah, I was just reminded of a thought I had during testing of the first version: with the actions/cache the save is deferred at the end of the workflow, which may include additional step the user is performing after loading and executing setup-dune (which I do in some repos) versus with the explicit save, the save is done as part of the setup-dune workflow (not at the end). Not exactly sure how this matters, but I had forgotten about this difference when writing the follow up exploratory changes and that specific difference might not be in favor of the explicit save (I'd have to think more about this). Just an additional data point for us to consider!