-
Notifications
You must be signed in to change notification settings - Fork 116
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
Track Cargo.lock
files to improve CI speed
#295
Conversation
Running |
Seems like a7cc7da just broke caching again :/ |
|
Wait, what? Thats wild, I'll have to look into that. |
Not really, but it's much worse for --all-features With just |
The annoying thing is that it's not consistent, for instance, I just ran the --all-features again and got 4.86s for generics.rs |
Any idea what's slow here? |
Even something like |
If that's the case, maybe merging #293 will make it faster? |
Sorry, I've got clue either |
Some things got faster with #293, but overall, |
So... I removed all mentions to TS in |
Yeah, I think you're onto something. It seems to be just the tests that are painfully slow. I'm not familiar with the internals, but there's some machinery around rust tests, so maybe that makes them compile very slowly? A clean debug build of our |
I have managed to get test compile times way down by changing the test profile and making all the tests into a single test binary. I'll push it here and check if CI gets faster. This was done by moving all tests from |
CI is now down to 49 seconds! |
This single binary compiles in 8-10 seconds on my machine |
CI is now under one minute and no longer emits any deprecation warnings |
Is there a reason why all the tests had to be moved into their own directory? |
Any file directly inside the By doing this, only one binary is created ( |
I think I can do something better though...
|
Small update: CI is now in the range of 40s-1min |
Hey @NyxCode, what do you think of the current state of this PR? |
I'm very happy with this, thanks! CI stuff always gives me headaches, so I try to avoid dealing with it ^^ Is there anything we should keep in mind now that we've got the |
I don't think there's much to worry about other than, as you said, running
We'd be succeptible to this anyway, in the previous setup, due to the lack of a Cargo.lock, CI would always use the latest patch version |
Goal
In #258 we added caching to our CI to reduce the time it takes to run. In the rust-cache docs it's mentioned that having the
Cargo.lock
files on GitHub improves the cache's effectiveness, and from what I have seen from the 2 last CI runs in this branch, CI running time has been cut down bya full minuteabout 20-30 seconds, (the one minute difference was caused by the initial commit being slower than usual).For some reason, the log message gets stuck like this
for a lot of time in the
--all-features
test, even though all the dependencies are already compiledChanges
.gitignore
actions-rs/toolchain
withdtolnay/rust-toolchain
tests/main.rs
Sources
https://fasterthanli.me/articles/why-is-my-rust-build-so-slow
https://corrode.dev/blog/tips-for-faster-rust-compile-times/#combine-all-integration-tests-into-a-single-binary
https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html