-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI cache does not update #98
Comments
In the workflow file, the If we do not find So we need to explicitly change the key whenever we want to be sure that we test a specific coq version. For example, we could add a variable to the workspace file to explicitly pin the tested version, and add this to the key-string. I initially thought of using the opam file hash as suffix of the key and add the largest tested coq version, but that would mean we must watch out to not accidentally releasing an opam-package that does not work with new minor versions by default. |
Can we counter this by always specifying the exact upper bound in the |
Yes, but then we must make sure to either not include the upper bound in the coq-opam repo. I think we should just mention and pin coq explicitly in the CI-file. |
We could include the hash of the commit inside the key at the end to disable the keep-found-caches-without-update feature, and use the current key as restore-key. |
related: actions/cache#171 and actions/cache#109 |
The fixlevel-release of Coq 8.12.1 did impact our library - in fact compilation broke. We just fixed the issue way before we bumped CI to 8.12.1. I think it's good to include an upper bound explicitly, especially in a phase like now were development is very active. At the same point were we bump CI we can bump the official opam release. |
Currently, after each PR the CI runs
opam upgrade
each time resulting inupgrade coq 8.12.0 to 8.12.1
.This should be done by the cache (and run only once) which currently does not seem to update correctly.
The text was updated successfully, but these errors were encountered: