-
-
Notifications
You must be signed in to change notification settings - Fork 145
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
chore: check minimal versions on CI #596
Conversation
a254c47
to
22534d2
Compare
As reported in issue #592, in our release of `console-api` 0.8.1, we specified that we required a tonic version of 0.12 in teh Cargo.toml file. However, since we had generated Rust code with `tonic-build` 0.12.3, we had some code that was only present in `tonic` from 0.12.3 as well. This error was fixed in #593. However, this showed a gap in our CI testing, we don't test against minimum versions of our dependencies to catch this kind of error. This change adds a CI job to check the minimal versions of our direct dependencies. We perform a cargo update with the `-Z direct-minimal-versions` flag and then perform cargo check. This would have caught the previous error and will catch any new ones of a similar type. One downside to this approach is that we must explicitly give a minimum version for our direct dependencies that is equal to or greater than the minimum version that any of of transitive dependencies specify for that same crate. However this check is probably worth the annoyance.
22534d2
to
341c02b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
@@ -25,6 +25,8 @@ env: | |||
RUSTUP_MAX_RETRIES: 10 | |||
# Don't emit giant backtraces in the CI logs. | |||
RUST_BACKTRACE: short | |||
# Pin a nightly version for minimal versions | |||
rust_nightly: nightly-2024-05-05 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May I ask why we need to pin the nightly version here? Is it to avoid breaking changes from Cargo's resolver?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nightly versions may not always work. So we're pinning this to avoid flaky tests depending on the most recent nightly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Thank you!
run: | | ||
# Remove dev-dependencies from Cargo.toml to prevent the next `cargo update` | ||
# from determining minimal versions based on dev-dependencies. | ||
cargo hack --remove-dev-deps --workspace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is for rust-lang/cargo#5657 (comment)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also just because we don't need to have exact versions for dev dependencies (since it doesn't affect crates that depend on us).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Thanks! 👍
As reported in issue #592, in our release of
console-api
0.8.1, wespecified that we required a tonic version of 0.12 in teh Cargo.toml
file. However, since we had generated Rust code with
tonic-build
0.12.3, we had some code that was only present in
tonic
from 0.12.3as well.
This error was fixed in #593.
However, this showed a gap in our CI testing, we don't test against
minimum versions of our dependencies to catch this kind of error.
This change adds a CI job to check the minimal versions of our direct
dependencies. We perform a cargo update with the
-Z direct-minimal-versions
flag and then perform cargo check. This wouldhave caught the previous error and will catch any new ones of a similar
type.
One downside to this approach is that we must explicitly give a minimum
version for our direct dependencies that is equal to or greater than the
minimum version that any of of transitive dependencies specify for that
same crate. However this check is probably worth the annoyance.