-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Remove optimal xz settings from CI #109888
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
Conversation
This is a companion PR to rust-lang/promote-release#58, which moves the relevant optimal code to rust-lang/promote-release. As mentioned in the comments of that PR, this is expected to cut CI costs (and time, though predominantly felt on fast builders) and reduce wasted resources due to in-practice single-threaded compression not using the full 8+ vCPU builders we have available.
@bors try |
⌛ Trying commit 0da526b with merge c7d503a4986575621b97e3ec5e7e5403c4f9d55c... |
☀️ Try build successful - checks-actions |
r=me |
@bors r=pietroalbini rollup=iffy promote-release should recompress back to small sizes now that rust-lang/promote-release#58 has landed, so this should be good to go. |
@bors rollup=never - want to avoid putting this in a rollup actually, to give a clear step on timings |
☀️ Test successful - checks-actions |
Finished benchmarking commit (bd991d9): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
This is a companion PR to rust-lang/promote-release#58, which moves the relevant optimal code to rust-lang/promote-release. As mentioned in the comments of that PR, this is expected to cut CI costs (and time, though predominantly felt on fast builders) and reduce wasted resources due to in-practice single-threaded compression not using the full 8+ vCPU builders we have available.
This probably shouldn't land before that PR + a simpleinfra change to enable the recompression of xz artifacts. But if it does land, it's just a matter of a few nightlies with slightly larger artifacts, so not a big deal.
r? @pietroalbini