setup-ocaml
setup-ocaml copied to clipboard
ocaml
Cache keys
- Due to https://github.com/actions/cache/issues/2 I need to use some hack to manually clear the cache of a broken OCaml 5 build, but I could not find the cache keys without digging into the source code. Could we possibly have all the keys documented somewhere?
- To solve my immediate problem I did dig into it. However, I'm confused by the current naming schemes. It seems the code is appending non-essential, changing information such as dates (years, weeks, and dates) and workflow run identifiers (run ids, run numbers) to the cache keys. I believe the keys should contain only essential information, and we should simply overwrite older copies. The only reason I could think of for attaching non-essential info is to using the older copies of the OPAM repositories, but this means the cache is potentially changing the semantics of the CI: even with the cache, the CI should always try to approximate "building and running the code from scratch now" as much as possible.
The underlying problem is that you can't overwrite the old cache. In the meantime, these are pretty deep and well figured cache keys that are still needed.
In the meantime, these are pretty deep and well figured cache keys that are still needed.
@smorimoto Thanks. Could you possibly elaborate a bit on why the components I pointed out are needed? I already made a PR #533 that details my suggestion. Based on your response, I suppose you do not support #533, but I don't understand what could go wrong with it. To clarify, I did not suggest to remove all keys, but only some components of them. Being unable to overwrite old cache is only part of the problem that is unique to GitHub, which can be worked around with a different prefix. Using multiple keys for essentially the same thing will also speed up the eviction of other cache that could otherwise stay. If possible, I'd like to hear more about your supposedly negative feedback to #533.
Sorry for being late. I was a little busy. I will be able to write all the explanations this weekend.
Hi I am closing this because I don't have time working on this now, and the CI will work correctly regardless of the final decision. (This issue is about improving efficiency, not correctness.)