[Merged by Bors] - Parameterize nightly toolchain in CI #5330
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
cart
approved these changes
Jul 15, 2022
|
bors r+ |
bors bot
pushed a commit
that referenced
this pull request
Jul 15, 2022
# Objective Rust's nightly builds semi-regularly break us (or our dependencies). This creates churn and angst when we're just trying to get our jobs done. We do still want nightly builds for a variety of reasons: * cargo-udeps requires nightly and likely always will. * Helps us catch rust nightly bugs quickly. We're "good citizens" if we regularly report regressions. * Lets us prepare for "actual expected breakage" ahead of stable releases so we avoid breaking main users. ## Solution * This pr parameterizes the nightly toolchain, making it an easy one-liner to pin our builds to a specific nightly, when required. * Put nightly jobs to check wasm and nightly on their own matrix. I also removed tests on nightly linux, just build check * alternative to #5329
|
Build failed: |
|
Just for additional data points, there was a recent Reddit discussion about how the actions-rs suite of GHA steps was falling unmaintained here. Based on the comments, I hope to evaluate https://github.com/dtolnay/rust-toolchain as a replacement on my personal projects. |
|
bors retry |
Ooh good to be aware of. Thanks! |
bors bot
pushed a commit
that referenced
this pull request
Jul 15, 2022
# Objective Rust's nightly builds semi-regularly break us (or our dependencies). This creates churn and angst when we're just trying to get our jobs done. We do still want nightly builds for a variety of reasons: * cargo-udeps requires nightly and likely always will. * Helps us catch rust nightly bugs quickly. We're "good citizens" if we regularly report regressions. * Lets us prepare for "actual expected breakage" ahead of stable releases so we avoid breaking main users. ## Solution * This pr parameterizes the nightly toolchain, making it an easy one-liner to pin our builds to a specific nightly, when required. * Put nightly jobs to check wasm and nightly on their own matrix. I also removed tests on nightly linux, just build check * alternative to #5329
|
Canceled. |
|
bors r+ |
bors bot
pushed a commit
that referenced
this pull request
Jul 15, 2022
# Objective Rust's nightly builds semi-regularly break us (or our dependencies). This creates churn and angst when we're just trying to get our jobs done. We do still want nightly builds for a variety of reasons: * cargo-udeps requires nightly and likely always will. * Helps us catch rust nightly bugs quickly. We're "good citizens" if we regularly report regressions. * Lets us prepare for "actual expected breakage" ahead of stable releases so we avoid breaking main users. ## Solution * This pr parameterizes the nightly toolchain, making it an easy one-liner to pin our builds to a specific nightly, when required. * Put nightly jobs to check wasm and nightly on their own matrix. I also removed tests on nightly linux, just build check * alternative to #5329
|
Canceled. |
|
bors r+ |
bors bot
pushed a commit
that referenced
this pull request
Jul 15, 2022
# Objective Rust's nightly builds semi-regularly break us (or our dependencies). This creates churn and angst when we're just trying to get our jobs done. We do still want nightly builds for a variety of reasons: * cargo-udeps requires nightly and likely always will. * Helps us catch rust nightly bugs quickly. We're "good citizens" if we regularly report regressions. * Lets us prepare for "actual expected breakage" ahead of stable releases so we avoid breaking main users. ## Solution * This pr parameterizes the nightly toolchain, making it an easy one-liner to pin our builds to a specific nightly, when required. * Put nightly jobs to check wasm and nightly on their own matrix. I also removed tests on nightly linux, just build check * alternative to #5329 Co-authored-by: Carter Anderson <mcanders1@gmail.com>
inodentry
pushed a commit
to IyesGames/bevy
that referenced
this pull request
Aug 8, 2022
# Objective Rust's nightly builds semi-regularly break us (or our dependencies). This creates churn and angst when we're just trying to get our jobs done. We do still want nightly builds for a variety of reasons: * cargo-udeps requires nightly and likely always will. * Helps us catch rust nightly bugs quickly. We're "good citizens" if we regularly report regressions. * Lets us prepare for "actual expected breakage" ahead of stable releases so we avoid breaking main users. ## Solution * This pr parameterizes the nightly toolchain, making it an easy one-liner to pin our builds to a specific nightly, when required. * Put nightly jobs to check wasm and nightly on their own matrix. I also removed tests on nightly linux, just build check * alternative to bevyengine#5329 Co-authored-by: Carter Anderson <mcanders1@gmail.com>
james7132
pushed a commit
to james7132/bevy
that referenced
this pull request
Oct 28, 2022
# Objective Rust's nightly builds semi-regularly break us (or our dependencies). This creates churn and angst when we're just trying to get our jobs done. We do still want nightly builds for a variety of reasons: * cargo-udeps requires nightly and likely always will. * Helps us catch rust nightly bugs quickly. We're "good citizens" if we regularly report regressions. * Lets us prepare for "actual expected breakage" ahead of stable releases so we avoid breaking main users. ## Solution * This pr parameterizes the nightly toolchain, making it an easy one-liner to pin our builds to a specific nightly, when required. * Put nightly jobs to check wasm and nightly on their own matrix. I also removed tests on nightly linux, just build check * alternative to bevyengine#5329 Co-authored-by: Carter Anderson <mcanders1@gmail.com>
ItsDoot
pushed a commit
to ItsDoot/bevy
that referenced
this pull request
Feb 1, 2023
# Objective Rust's nightly builds semi-regularly break us (or our dependencies). This creates churn and angst when we're just trying to get our jobs done. We do still want nightly builds for a variety of reasons: * cargo-udeps requires nightly and likely always will. * Helps us catch rust nightly bugs quickly. We're "good citizens" if we regularly report regressions. * Lets us prepare for "actual expected breakage" ahead of stable releases so we avoid breaking main users. ## Solution * This pr parameterizes the nightly toolchain, making it an easy one-liner to pin our builds to a specific nightly, when required. * Put nightly jobs to check wasm and nightly on their own matrix. I also removed tests on nightly linux, just build check * alternative to bevyengine#5329 Co-authored-by: Carter Anderson <mcanders1@gmail.com>
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.
Objective
Rust's nightly builds semi-regularly break us (or our dependencies). This creates churn and angst when we're just trying to get our jobs done.
We do still want nightly builds for a variety of reasons:
Solution