-
Notifications
You must be signed in to change notification settings - Fork 120
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
fix(s2n-quic-rustls, s2n-quic-tls): enable building with default features #1673
Conversation
.github/workflows/ci.yml
Outdated
@@ -16,6 +16,7 @@ env: | |||
# Pin the nightly toolchain to prevent breakage. | |||
# This should be occasionally updated. | |||
RUST_NIGHTLY_TOOLCHAIN: nightly-2023-02-20 | |||
MSRV: 1.63 |
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.
We seem to already have a msrv that we parse from the rust-toolchain below in env
. Do we also need this?
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.
Good call out, will update.
This also fails on crates that are marked |
I opened a draft PR with just the workflow changes to make sure that it breaks on our current state, and the task was failed successfully #1676. The new workflow failed on h3, tls, and rustls as expected. |
Description of changes:
Note that the name of this PR is confusing. "default" features is literally referring to "the set of features included when build is invoked directly on the package", and not necessarily cargo's concept of "default-features".
Currently we are unable to release to crates.io because
s2n-quic-rustls
ands2n-quic-tls
do not build with default features. This happened because in a #1633 , components thats2n-quic-rustls
depends on were moved behind thealloc
feature flag.We failed to detect this in our CI because the workspace build builds from
s2n-quic
withdefault
features enabled. This build happens successfully because thealloc
feature is included indefault
.An issue that seems to describe in a bit more detail is linked here: rust-lang/cargo#8366
Call-outs:
I'm still a bit uncertain on our overall story for no-std usage. It might be good to add an example showing an intended use case.
Why not just dry run publishing/packaging?
Because that relies on artifacts being published to crates.io
For example consider that we just version bumped things so that for crate A which consumes B, we now have
A = 1.0.0 depends on B = 1.0.0.
The same problem applies to the
cargo package
workflow.Testing:
Tested by invoking the individual package builds. Also adding a step for that to the CI. The list of packages that are will be dynamically updated.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.