Is Running Clippy in CI as Good as Running a Build?

[zicklag]

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]

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 )

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.

[zicklag]

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.

That's nice. 👍

given that there are no test suites in the project,

Ah, that would be why you would need to do a full build. I forgot about tests. But yeah, you're right, we don't have any tests for now, other than the tiny set that I wrote for the URL query string parser, which isn't something that needs to be run on every commit.

At the same time, if we are going to have tests later, it might be worth keeping the builds around, and maybe even running cargo test just so that it's setup for when we do have tests.

I'm not sure. I'm not strongly leaning in any one direction at this point.

[64kramsystem]

It depends on how significant are the UT, in particular:

• is the code tested fragile?
• is it platform-dependent (so that they don't need multiple builds)

Regardless, the decision is not permanent - if we go for removing the build caches, we can restore the build when we want, with little effort (the effort being implementing a more resource-aware design).

[64kramsystem]

I'm going to convert this to an issue, since regardless of the outcome, we'll need to do something (at the very least, remove the Build caches workflow.