ci: remove binary size check #710
ci: remove binary size check #710
Conversation
|
And anything which depends on an implementation in YamlScript is right the fuck out. |
|
If the goal is to delete the current implementation and add back something different later, all of .github/actions can get wiped too. +1 to getting rid of this, probably should have been a python script if something more json-capable than bash was needed. It's impossible to repro this job locally as-is. |
Remove the "binary size check" workflow because it is often broken and now and then makes me sit through a discussion about its security needs. These discussions always make me feel very silly. I originally hoped this CI job would be a useful part of assuring that we would not accidentally bloat binaries when backtrace merges into std. However, it feels like that is not achieved by this workflow and at some point it has definitely outweighed the cost of maintaining it. We can readd something if we find a better way to implement things which is notably less jank and gets less complaints.
55e8a40 to
7718dae
Compare
|
Good catch. Thank you. |
|
If you do wind up reimplementing, I have some logic for finding the exact PR diff that you could probably steal https://github.com/rust-lang/compiler-builtins/blob/a4c748f72a1dce652cc3e41c3a8425731bd1519a/ci/ci-util.py#L124-L179 (used there for running the multi-hour tests only if relevant files changed) and for comparing to a baseline that was saved as an artifact https://github.com/rust-lang/compiler-builtins/blob/a4c748f72a1dce652cc3e41c3a8425731bd1519a/ci/ci-util.py#L271-L343 (the icount benchmarks use the latest run on master as a baseline rather than running twice across the diff). I'm not "very satisfied" with that solution because it seems like those things should be way easier, but I would say "somewhat satisfied" since it's been reasonably problem-free for a while. |
Remove the "binary size check" workflow because it is often broken and now and then makes me sit through a discussion about its security needs. These discussions always make me feel very silly.
I originally hoped this CI job would be a useful part of assuring that we would not accidentally bloat binaries when backtrace merges into std. However, it feels like that is not achieved by this workflow and at some point it has definitely outweighed the cost of maintaining it.
We can readd something if we find a better way to implement things which is notably less jank and gets less complaints.