-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
The toml workflow job will now install taplo-cli using cargo-binstall #18773
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
The toml workflow job will now install taplo-cli using cargo-binstall #18773
Conversation
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.
That's a solid argument. I'm not worried about the MSRV: Bevy's MSRV will almost certainly run ahead of this.
I proposed to use |
Co-authored-by: François Mockers <francois.mockers@vleue.com>
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.
Outside of the one issue, looks good overall.
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.
LGTM; seems to be running correctly in the CI checks on this PR.
…bevyengine#18773) # Objective Avoid needing to compile `taplo-cli` every time we use it in CI. ## Solution Use [cargo-binstall](https://github.com/cargo-bins/cargo-binstall) to install `taplo-cli`. cargo-binstall is different from `cargo install`, in that it will first attempt download a precompiled `taplo-cli` binary, in an attempt to avoid compilation. However, failing that (for any reason), it will fall back to installing the binary through `cargo install`. While installing `taplo-cli` from source is relatively fast (around 50-60s), this still provides a small speed boost to the job, by not needing to spend time compiling `taplo-cli` from source at all. ## Note on how this affects workflows This PR does have one side-effect: Should `taplo-cli` need to be compiled from source at all, it is no longer guaranteed to use the latest `stable` version of `rustc`. This may be considered problematic, as `taplo-cli` doesn't appear to have a MSRV policy. However, its MSRV (as of writing this PR) is `1.74` - a nearly 1.5 year old version. This seems to imply that, if `taplo-cli`'s MSRV is ever updated, it won't be to the absolute latest stable version of Rust until said version is a few months old. Combine that with [the Github Actions runner images being frequently (and automatically) updated to use the latest Rust tooling](actions/runner-images#11957), and I don't foresee `taplo-cli`'s MSRV being an issue in 99% of circumstances. Still, there is the possibility of it being a problem in those 1% of circumstances - if this is a concern, please let me know and I'll try to fix it. ## Testing This change was tested on my local fork. The specific job run can be found [here](https://github.com/LikeLakers2/bevy/actions/runs/14350945588/job/40229485624). --------- Co-authored-by: François Mockers <francois.mockers@vleue.com>
Objective
Avoid needing to compile
taplo-cli
every time we use it in CI.Solution
Use cargo-binstall to install
taplo-cli
.cargo-binstall is different from
cargo install
, in that it will first attempt download a precompiledtaplo-cli
binary, in an attempt to avoid compilation. However, failing that (for any reason), it will fall back to installing the binary throughcargo install
.While installing
taplo-cli
from source is relatively fast (around 50-60s), this still provides a small speed boost to the job, by not needing to spend time compilingtaplo-cli
from source at all.Note on how this affects workflows
This PR does have one side-effect: Should
taplo-cli
need to be compiled from source at all, it is no longer guaranteed to use the lateststable
version ofrustc
. This may be considered problematic, astaplo-cli
doesn't appear to have a MSRV policy.However, its MSRV (as of writing this PR) is
1.74
- a nearly 1.5 year old version. This seems to imply that, iftaplo-cli
's MSRV is ever updated, it won't be to the absolute latest stable version of Rust until said version is a few months old.Combine that with the Github Actions runner images being frequently (and automatically) updated to use the latest Rust tooling, and I don't foresee
taplo-cli
's MSRV being an issue in 99% of circumstances.Still, there is the possibility of it being a problem in those 1% of circumstances - if this is a concern, please let me know and I'll try to fix it.
Testing
This change was tested on my local fork. The specific job run can be found here.