CI: fix minimal-versions resolution #593
Conversation
tarcieri
force-pushed
the
fix-minimal-versions-resolution
branch
from
6a6a8d0
to
e760df2
Compare
|
Unused import stuff is fixed in #590 |
|
It is? How? Regardless, this approach should be more futureproof in regard to any other nightly regressions. |
| @@ -85,7 +87,7 @@ jobs: | |||
| runs-on: ubuntu-latest | |||
| steps: | |||
| - uses: actions/checkout@v3 | |||
| - uses: dtolnay/rust-toolchain@nightly | |||
| - uses: dtolnay/rust-toolchain@1.73.0 | |||
There was a problem hiding this comment.
We should definitely pin clippy rather than running nightly clippy
|
Some of the contents of I agree about the CI being more robust. My only concern is that this adds another chore (updating pinned nightly). Is there a buildabot type automation for this? |
|
Merged |
To avoid nightly regressions breaking the build, the CI configuration has been updated to *only* use nightly for resolving Cargo.lock by using `cargo update -Z minimal-versions`. Previously, it was running `cargo check` which would attempt to compile all of the dependencies and the code, which is why the diagnostic bug was triggered. By avoiding any kind of code compilation using nightly we can avoid such regressions in the future. Additionally, the clippy job has been changed to run on the latest stable release (1.73.0) rather than nightly, which will prevent future clippy lints from breaking the build. Instead, they can be addressed when clippy is updated.
tarcieri
force-pushed
the
fix-minimal-versions-resolution
branch
from
e760df2
to
0c026ec
Compare
|
Updated with the I still think the other changes simplify/stabilize the build if we don't do that, but personally I find it frustrating whenever the build breaks due to things unrelated to my changes. |
|
I agree. If we had a more streamlined way of addressing it separately from our PRs then I'd go for it. Only reason I think we should have nightly in the CI is bc it forces us to make changes for what's coming down the pike into stable. If you still think it's more reasonable to pin, though, then I'm happy to do it |
|
Let's cross that bridge when we get there (again), I guess. At least these changes will limit the scope of the failures to the nightly test. |
To avoid nightly regressions breaking the build, the CI configuration has been updated to only use nightly for resolving Cargo.lock by using
cargo update -Z minimal-versions.Previously, it was running
cargo checkwhich would attempt to compile all of the dependencies and the code, which is why the diagnostic bug was triggered. By avoiding any kind of code compilation using nightly we can avoid such regressions in the future.Additionally, the clippy job has been changed to run on the latest stable release (1.73.0) rather than nightly, which will prevent future clippy lints from breaking the build. Instead, they can be addressed when clippy is updated.