-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Test clippy on PR CI on changes #77016
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
I pulled the 30 second figure from this build (https://github.com/rust-lang-ci/rust/runs/1142917610?check_suite_focus=true) fwiw, but generally ~500 ui tests are going to be pretty fast. (For comparison, regular UI tests for rustc are currently at around 11,000). |
Note that this went from 35 minutes to 40 minutes. I haven't looked into the detailed timings. |
I've seen natural variability of +/- 3-4 minutes on past PRs, but it does look like clippy tests took 2m40s on that PR run -- I guess I looked at the wrong thing or something (maybe excluded clippy build? Not sure). |
I don't know that we have a process for approving these -- without capacity figures it's hard to tell. I'd say it's worth it personally. |
Let's nominate infra on this. @rustbot modify labels: I-nominated |
@rust-lang/clippy @RalfJung -- do we know how common it is for these tests to start failing in PR CI? We were discussing this in the infra team meeting and @pietroalbini brought up the good point that if we're slowing down PR CI by 5 minutes (15%) that's not nothing. If we expect these failures to be really rare, then it probably makes sense to not do this. (It also looks like there's not a heuristic we can use to determine if running clippy tests makes sense, right? e.g. a file that's usually touched if clippy is to fail, or something in the diff) |
Major compiler changes typically cause failures. We used to have a lot more, stuff has quieted down now but it still happens. |
So, clippy's tests should not take that long to run. The slow thing is the dogfood clippy run -- running clippy on clippy. Perhaps that test can be excluded from CI? It's not a huge deal if that fails. |
Hm, so we'd pass whatever the libtest ignore is for dogfood? I could hook that up, though it'd be a bit painful to do it just on the PR builder. We probably want it in mainline CI though right? |
Yeah ideally clippy CI doesn't differ between rust-clippy and rust. |
Currently only the UI-tests and UI-toml tests are run in the rust repo. UI-cargo, dogfood and fmt tests are excluded in the Rust CI. Clippy also takes 2-3min to build, so the additional time probably comes from the build. A simple heuristic that may improve the situation a bit is to at least run Clippy tests, if files in Clippy currently needs about 1-3 syncs per week -> 1-3 PRs break Clippy per week. So I don't think always running Clippy tests is necessary. |
Hmm, with so few PRs being affected by this I don't think it's worth slowing CI down by 5 minutes. If the |
Yes it does, but currently only on bors runs and then for all tools, IIUC. But if it's possible to filter the tested tools in this builder, that SGTM. Or more generally for the future: if a |
Sounds good! Then, I think this PR should update |
@Mark-Simulacrum any updates? |
706ac66
to
38771ae
Compare
38771ae
to
d847299
Compare
r? @pietroalbini -- this should be updated to just test clippy when it's been modified |
@bors r+ |
📌 Commit d847299 has been approved by |
Rollup of 12 pull requests Successful merges: - rust-lang#74754 (Add `#[cfg(panic = '...')]`) - rust-lang#76468 (Improve lifetime name annotations for closures & async functions) - rust-lang#77016 (Test clippy on PR CI on changes) - rust-lang#78480 (BTreeMap: fix pointer provenance rules) - rust-lang#78502 (Update Chalk to 0.36.0) - rust-lang#78513 (Infer the default host target from the host toolchain if possible) - rust-lang#78566 (Enable LLVM Polly via llvm-args.) - rust-lang#78580 (inliner: Break inlining cycles) - rust-lang#78710 (rustc_ast: Do not panic by default when visiting macro calls) - rust-lang#78746 (Demote i686-unknown-freebsd to tier 2 compiler target) - rust-lang#78830 (fix `super_visit_with` for `Terminator`) - rust-lang#78844 (Monomorphize a type argument of size-of operation during codegen) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This runs the tools builder (which builds and tests tools, including clippy) when the clippy submodule changes. This essentially returns us to the prior state when clippy was a submodule; it makes sense for us to test it on CI when it changes. It might make sense for it to be tested regardless of changing but it is somewhat rare for it to fail and we don't want to add to CI time for the majority of PRs which don't affect it.
Fixes #76999.