chore: check minimal versions on CI #596
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hds
force-pushed
the
hds/check-minimal-versions
branch
3 times, most recently
from
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.
hds
force-pushed
the
hds/check-minimal-versions
branch
from
22534d2
to
341c02b
Compare
| @@ -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.
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.
Nightly versions may not always work. So we're pinning this to avoid flaky tests depending on the most recent nightly.
| 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.
I guess this is for rust-lang/cargo#5657 (comment)?
There was a problem hiding this comment.
Also just because we don't need to have exact versions for dev dependencies (since it doesn't affect crates that depend on us).
Rustin170506
approved these changes
Nov 12, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As reported in issue #592, in our release of
console-api0.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-build0.12.3, we had some code that was only present in
tonicfrom 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-versionsflag 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.