Slim down project build in Github workflows
64kramsystem opened this issue · comments
Discussed in #136
Originally posted by zicklag July 25, 2022
For some reason, maybe just because we have a lot of dependencies, our builds are taking a pretty long time. 13 minutes for the Linux build, thought we somehow got 13 seconds with the Mac build ).
It's probably because we're running out of cache space and it just starts deleting some of our caches resulting in the cached builds running really fast and the un-cached builds taking the hit.
Anyway, I just realized, though, why do we actually need to run a full build for CI? Can't we just cargo check ( or better yet cargo clippy ) on all of the target backends instead? We're not going to use the built artifacts for anything from CI. I can't think of any real code problems that that wouldn't detect other than linker errors.
There are some crates/tools that cause linker errors to prevent you from doing certain things, but those are usually hacky workarounds for something like a way to prevent you from inserting unsafe code into a function. If we're not using anything like that, I think a cargo check in CI should be just about as good as a cargo build. Then we only need to do actual cargo builds on releases.
There might be a scenario I'm not thinking of. What do you think? @odecay @64kramsystem @orhun
64kramsystem response:
I'm not 100% sure why builds are so slow, as 10 GB should be enough, however, given that there are no test suites in the project, bulding only for tags makes sense.
Also, now that the CI workflow builds also on master, we don't need the Build caches workflow anymore, so it's additional resources freed.
I agree with this. It seems unnecessary to do a full build if we can get away with cargo check/cargo clippy. I'd be interested in hearing if anyone thinks there is a good reason not to do that though.
On a side note it would be nice if we also did so with --features=debug enabled because it's been ending up broken relatively frequently due to it being another thing to test.
Edit: I missed the discussion on the implications for testing which I've now seen.
I think this is a good call. Normally I would prefer cargo build over cargo check to potentially detect linker errors but I don't think that is crucial for this case. Running only cargo clippy also sounds fine since it checks the code as well.
OK, sounds like we move to just checking for now.