jasmin-lang
Switch from Gitlab's CI to GitHub actions
One big advantage would be to have the CI results reported inside the PRs. A first try was attempted in https://github.com/jasmin-lang/jasmin/pull/96 but reverted in https://github.com/jasmin-lang/jasmin/pull/105 due to some limitations of the implementation.
Here is the list of points that were identified as blocking the replacement of GitLab's CI with GitHub's CI:
- [x] The OPAM cache gets corrupted regularly, so this should either be fixed or circumvented (e.g. by providing a nice way to clear the cache manually): done, see https://github.com/jasmin-lang/jasmin/pull/109
- [ ] The push-compiler-code job must not run on PRs (and other WIP branches), ideally only on some chosen branches, e.g. the protected branches
- [ ] GitLab's CI must be removed before merging if we are happy with GitHub actions
- The OPAM cache gets corrupted regularly
Pointers to example failures welcome (maybe to Gitlab jobs, in fact, as it will be easier to verify that the fix is effective).
Here is a pointer to a failure of a GitHub job : https://github.com/jasmin-lang/jasmin/runs/6080469236?check_suite_focus=true.
The same failure on GitLab: https://gitlab.com/jasmin-lang/jasmin/-/jobs/2340273098.
@vbgl Is https://github.com/jasmin-lang/jasmin/commit/f5d67c23878204e4d60ccd7a604c9ccf83c938dd solving the cache issue mentioned above?
It should. Apparently the problem was the invocation of nix-shell -p which was not reproducible. Now we always rely on default.nix which pins the versions of the dependencies. So as long as we don't touch the hash in https://github.com/jasmin-lang/jasmin/blob/main/scripts/nixpkgs.nix, the cache should not become out-of-sync. If we want to upgrade the dependencies, we have to change the hash and afterwards clear the cache.
FTR, if you put a # before the issue number in the commit message, it will make a link appear here. We started looking at it before realizing it probably was already fixed (before spending a significant amount of time, fortunately).
What @maximedenes suggests for point 3 of the issue is to keep the two CI systems during a certain transition period (e.g. a few weeks), just to have the time to test it and make sure that the one based on Github Actions is working properly. We can use this issue to keep track of that, so that we are sure we end up with only one CI system at some point.
One way to have an automatic invalidation of the cache when changing the hash in nixpkgs.nix would be to include this hash in the key, either manually or automatically (probably some nix utility can print it?).
@maximedenes you may want to know that not only https://github.com/jasmin-lang/jasmin/pull/109 but also PR https://github.com/jasmin-lang/jasmin/pull/110 touched the GitLab CI. We certainly have to reflect these changes on GitHub's side. Would you mind doing that? I don't think that is a lot of work, but I can try to do it too if you want.
@vbgl found a way to report the CI status (run on Gitlab) to the corresponding PR (on GitHub). See for instance PR https://github.com/jasmin-lang/jasmin/pull/158. This is not as well integrated as using native GitHub CI, but should be enough to make it usable by anyone. Should we close this issue then? It seems that, at least in the near future, we are sticking to using GitLab for CI.