namanjain24-sudo commented on issue #25148: URL: https://github.com/apache/datafusion/issues/25148#issuecomment-5636985101
@adriangb two corrections to what you quoted, and then the answer to your question. **"They are all `Required`" was wrong.** Six of the seven are. `cargo check datafusion-ffi features` is not in `.asf.yaml`'s `required_status_checks`; the other six are. My point about merge-queue start latency still holds for those six, but I overstated it. **"the largest single saving available inside this repo" was also too strong**, and my own numbers say so. Folding the seven into one job serialises their check steps: on `merge_group` they sum to 17.9 median minutes while the slowest single one is 3.8, and the longest job anywhere in the workflow today is `cargo test (amd64)` at 5.7. So one merged job would become the new critical path and roughly double the workflow's wall clock. Total minutes would drop, wall clock would get worse. That is a real trade, not a free win, and I should not have written it as one. **On building the dependency graph once:** it is not happening today for most of them. Only `cargo check datafusion features` and `cargo check datafusion-substrait features` declare a `Rust Dependency Cache` step. The other five declare none at all: | job | `Rust Dependency Cache` | | --- | --- | | `cargo check datafusion features` | yes, `shared-key: amd-ci` | | `cargo check datafusion-substrait features` | yes, `shared-key: amd-ci` | | `cargo check datafusion-common features` | none | | `cargo check datafusion-proto features` | none | | `cargo check datafusion-ffi features` | none | | `cargo check datafusion-functions features` | none | | `cargo check datafusion-spark features` | none | Three of the seven are also pinned to `ubuntu-latest` rather than the `vars.USE_RUNS_ON` expression. I have not proposed changing that, since @blaginin said upthread that `runs-on` was disabled in places deliberately on cost grounds, so it is the same credits question rather than a cleanup. I opened #25195 for the part of this that needs no such decision: the substrait check job selects a `runs-on` runner but is the only one of the fifteen such jobs missing the `runs-on/action` step that registers it, and the spark job was the last place in `rust.yml` calling `cargo check` directly instead of going through `xtask`. Four lines, no job names changed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
