-
Notifications
You must be signed in to change notification settings - Fork 42
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: Use nix+cachix #126
ci: Use nix+cachix #126
Conversation
9751546
to
744c7d6
Compare
744c7d6
to
e47ef9c
Compare
This reverts commit b395ff9.
I closed and re-opened the PR to see about the clippy check. It seems that this may be an option set on the repository settings. I can try to tweak this to work with that, or maybe we can just make the CI action be the only thing required (see the diff and commits/action runs to see that clippy is enforced). This would explain #120 as well |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had clippy checked as a required action before merging to main. Went ahead and removed it so this should be good to go.
Switches CI actions to use nix, taking advantage of cachix to cache nix derivations.
The built packages and tests are ran inside a nix context using artifacts generated using crane which reduces repeated builds of dependencies that have not changed. This means that the build generated from a CI test run can be used directly to create a container image since it will be cached. This means in most cases (when the only code being changed is the code in this repository) the CI build times should be cut down significantly.
For running tests this uses cargo-nextest. It has been provided in the devshells.
As a result of runny clippy through crane, we are no longer using clippy-check and will no longer have the pretty display on the PR diff view. However the speed increase for CI is substantial in some cases (while remaining on par in others with the existing CI). Here are some example runs:
Action run when nothing needed rebuilt: ~2 minutes
Running tests: ~16 minutes
Building image: ~2 minutes (when the package has been cached due to a previous test)
Clippy failure check: ~9 minutes
From here this is still some potential for speedup in future work. Potentially running the actions on a NixOS host (or, at least a persistent runner) could help cache some dependencies between runs. There also may be other options for configuring the existing system that are not taken advantage of yet.