namanjain24-sudo commented on issue #25148: URL: https://github.com/apache/datafusion/issues/25148#issuecomment-5695194797
I pulled the per job timings for `rust.yml` from the Actions API to see where the minutes sit after #25203, #25231 and #25249, and the split by runner turned out to be the whole story. Seven days to 2026-09-16, 738 runs with job timings (496 `pull_request`, 133 `merge_group`, 109 `push`), 19,603 jobs: | runs | GitHub hosted | RunsOn | | --- | --- | --- | | `pull_request` | 60,697 min | 369 min | | `merge_group` | 4,074 min | 6,285 min | | `push` | 3,226 min | 4,982 min | **89% of the GitHub hosted minutes this workflow spends come from PR runs**, and they are hosted because `vars.USE_RUNS_ON` is empty for a fork. 486 of the 496 PR runs ran entirely on GitHub hosted runners. The 10 that used RunsOn are all branches in this repository: `dependabot/cargo/main/dirs-7`, `dependabot/github_actions/...` and so on. Every fork PR I sampled got none: `kosiew/datafusion`, `kumarUjjawal/datafusion`, `rluvaton/datafusion`, `lyne7-sc/datafusion`, `1fanwang/datafusion`. That is the fork point @AdamGS and @blaginin raised, measured: about 122 GitHub hosted minutes per PR run, 60,697 per week. For comparison, pushes to `main`, which #25365 targets, are 3,226 GitHub hosted minutes a week, and the merge queue is 4,074. Both are worth having, and neither moves the 60,697. Where the PR minutes go, GitHub hosted only, seven days: | job | minutes | avg | | --- | --- | --- | | `cargo test (amd64)` | 7,185 | 14.7 | | `cargo examples (amd64)` | 6,155 | 12.6 | | `verify benchmark results (amd64)` | 4,721 | 9.6 | | `clippy` | 3,633 | 7.4 | | `cargo check datafusion-substrait features` | 3,476 | 7.1 | | `cargo test doc (amd64)` | 3,347 | 6.8 | | `cargo check datafusion features` | 2,891 | 5.9 | | `linux build test` | 2,798 | 5.7 | | `cargo test (macos-aarch64)` | 2,680 | 5.3 | One more number: 111 of the 496 PR runs were cancelled, mostly by the concurrency group when a branch is pushed again. Those minutes are already spent when the cancel lands. So the lever that matters is making PR runs from forks use the same runners as the queue, rather than trimming what runs after a merge. The two approaches discussed above both do that: give the fork's own runners the work, as Comet does, or route fork PRs through this repository's RunsOn account. If it helps, I can put the collection script somewhere so the numbers can be refreshed rather than taken on trust. -- 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]
