Repository navigation
ci: share extended test commands through xtask - #25256
Merged
kumarUjjawal merged 2 commits intoSep 13, 2026
Merged
Conversation
Add `extended`, `hash-collisions`, and `sqlite` variants to `cargo xtask ci step test` so the three long-running suites in `extended.yml` are defined once and can be reproduced locally. Each variant owns its suite-specific environment: `extended` sets `RUST_BACKTRACE=1` and `DATAFUSION_SPILL_POOL_FUZZ_ITERATIONS=1000`, `hash-collisions` runs from the `datafusion` directory with `RUST_BACKTRACE=1`, and `sqlite` sets nothing because its CI job deliberately skips the builder setup. The workflow now calls the shared commands. Triggers, job IDs, display names, runners, containers, the clean working tree check, and `cargo clean` are unchanged, so the required merge-queue checks keep their identities. `--explain` prints each underlying command without running it; the README documents the commands, their environment, and prerequisites. Partial progress on apache#21048 and apache#24487. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2010YOUY01
approved these changes
Sep 13, 2026
Comment on lines
+43
to
+101
|
|
||
| ### Extended test suites | ||
|
|
||
| The [extended tests] are long-running suites that run in the merge queue, on | ||
| pushes to release branches, and on manual dispatch. They do not run on ordinary | ||
| pull request updates. Each job in [`extended.yml`] runs one of these commands: | ||
|
|
||
| | GitHub Actions job | Command | | ||
| | ---------------------------------------------- | ------------------------------------------ | | ||
| | `cargo test 'extended_tests' (amd64)` | `cargo xtask ci step test extended` | | ||
| | `cargo test hash collisions (amd64)` | `cargo xtask ci step test hash-collisions` | | ||
| | `Run sqllogictests with the sqlite test suite` | `cargo xtask ci step test sqlite` | | ||
|
|
||
| Append `--explain` to print the `cargo test` invocation, its working directory, | ||
| and the environment variables the command sets, without running the suite: | ||
|
|
||
| ```shell | ||
| cargo xtask ci step test extended --explain | ||
| cargo xtask ci step test hash-collisions --explain | ||
| cargo xtask ci step test sqlite --explain | ||
| ``` | ||
|
|
||
| Each command sets only the environment variables that its test suite needs. | ||
| Everything else is inherited from the calling shell: | ||
|
|
||
| - `extended` sets `RUST_BACKTRACE=1` and `DATAFUSION_SPILL_POOL_FUZZ_ITERATIONS=1000`. | ||
| The second variable runs more random spill pool fuzzer scenarios than the | ||
| default test suite does. | ||
| - `hash-collisions` runs from the `datafusion` directory and sets | ||
| `RUST_BACKTRACE=1`, which matches the CI builder setup for that job. | ||
| - `sqlite` sets no variables. Its CI job deliberately skips the builder setup | ||
| because backtraces make this suite much slower. A `RUST_BACKTRACE` value | ||
| inherited from your shell therefore makes a local run differ from CI. | ||
|
|
||
| #### Prerequisites | ||
|
|
||
| - The Rust toolchain from `rust-toolchain.toml` and the Protobuf compiler | ||
| (`protoc`). See the [development environment] guide. | ||
| - The test data submodules. The `sqlite` suite reads | ||
| `datafusion-testing/data/sqlite`: | ||
|
|
||
| ```shell | ||
| git submodule update --init --recursive | ||
| ``` | ||
|
|
||
| - Time and disk space. These suites build most of the workspace with test | ||
| features enabled, and the `sqlite` suite runs several million queries. | ||
|
|
||
| #### What a test command does not do | ||
|
|
||
| A test command reproduces one `cargo test` invocation from a CI job. It is not | ||
| the complete job. The GitHub Actions workflow still installs the toolchain, | ||
| configures build flags, caching, and network settings, verifies that the | ||
| working tree is clean, and runs `cargo clean`. The commands never run cleanup | ||
| and never call the GitHub API, so they are safe to run in a local checkout. | ||
|
|
||
| [extended tests]: https://github.com/apache/datafusion/blob/main/docs/source/contributor-guide/testing.md#extended-tests | ||
| [`extended.yml`]: https://github.com/apache/datafusion/blob/main/.github/workflows/extended.yml | ||
| [development environment]: https://github.com/apache/datafusion/blob/main/docs/source/contributor-guide/development_environment.md |
Contributor
There was a problem hiding this comment.
Suggested change
| ### Extended test suites | |
| The [extended tests] are long-running suites that run in the merge queue, on | |
| pushes to release branches, and on manual dispatch. They do not run on ordinary | |
| pull request updates. Each job in [`extended.yml`] runs one of these commands: | |
| | GitHub Actions job | Command | | |
| | ---------------------------------------------- | ------------------------------------------ | | |
| | `cargo test 'extended_tests' (amd64)` | `cargo xtask ci step test extended` | | |
| | `cargo test hash collisions (amd64)` | `cargo xtask ci step test hash-collisions` | | |
| | `Run sqllogictests with the sqlite test suite` | `cargo xtask ci step test sqlite` | | |
| Append `--explain` to print the `cargo test` invocation, its working directory, | |
| and the environment variables the command sets, without running the suite: | |
| ```shell | |
| cargo xtask ci step test extended --explain | |
| cargo xtask ci step test hash-collisions --explain | |
| cargo xtask ci step test sqlite --explain | |
| ``` | |
| Each command sets only the environment variables that its test suite needs. | |
| Everything else is inherited from the calling shell: | |
| - `extended` sets `RUST_BACKTRACE=1` and `DATAFUSION_SPILL_POOL_FUZZ_ITERATIONS=1000`. | |
| The second variable runs more random spill pool fuzzer scenarios than the | |
| default test suite does. | |
| - `hash-collisions` runs from the `datafusion` directory and sets | |
| `RUST_BACKTRACE=1`, which matches the CI builder setup for that job. | |
| - `sqlite` sets no variables. Its CI job deliberately skips the builder setup | |
| because backtraces make this suite much slower. A `RUST_BACKTRACE` value | |
| inherited from your shell therefore makes a local run differ from CI. | |
| #### Prerequisites | |
| - The Rust toolchain from `rust-toolchain.toml` and the Protobuf compiler | |
| (`protoc`). See the [development environment] guide. | |
| - The test data submodules. The `sqlite` suite reads | |
| `datafusion-testing/data/sqlite`: | |
| ```shell | |
| git submodule update --init --recursive | |
| ``` | |
| - Time and disk space. These suites build most of the workspace with test | |
| features enabled, and the `sqlite` suite runs several million queries. | |
| #### What a test command does not do | |
| A test command reproduces one `cargo test` invocation from a CI job. It is not | |
| the complete job. The GitHub Actions workflow still installs the toolchain, | |
| configures build flags, caching, and network settings, verifies that the | |
| working tree is clean, and runs `cargo clean`. The commands never run cleanup | |
| and never call the GitHub API, so they are safe to run in a local checkout. | |
| [extended tests]: https://github.com/apache/datafusion/blob/main/docs/source/contributor-guide/testing.md#extended-tests | |
| [`extended.yml`]: https://github.com/apache/datafusion/blob/main/.github/workflows/extended.yml | |
| [development environment]: https://github.com/apache/datafusion/blob/main/docs/source/contributor-guide/development_environment.md |
I think this change is related to specific test command, instead of xtask runner.
Now I think it's enough if we can keep them around the ci steps, later we might want to centralize somewhere, and let it show up in the explain like
yongting@Yongtings-MacBook-Pro-2 ~/C/d/datafusion (main) [1]> cargo xtask ci step test workspace --explain
#
# Run default test suite and generate codecov report <--- Here: per command explanation
#
cd /Users/yongting/Code/datafusion2/datafusion && \
cargo llvm-cov \
--profile ci \
--exclude datafusion-examples \
--exclude ffi_example_table_provider \
--exclude datafusion-cli \
--workspace \
--lib \
--tests \
--bins \
--features serde,avro,json,backtrace,integration-tests,parquet_encryption,substrait \
--codecov \
--output-path target/codecov.json
Contributor
Author
There was a problem hiding this comment.
Thank you sounds good!
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #25256 +/- ##
========================================
Coverage 81.88% 81.88%
========================================
Files 1133 1133
Lines 424522 424639 +117
Branches 424522 424639 +117
========================================
+ Hits 347623 347730 +107
- Misses 56285 56293 +8
- Partials 20614 20616 +2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Apply review feedback: the README describes the xtask runner, and the per-suite details belong next to the step definitions in `ci_steps.rs`, where the variant comments already record them. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Contributor
Author
|
Thank you @2010YOUY01 for the review. |
kumarUjjawal
enabled auto-merge
September 13, 2026 08:34
kumarUjjawal
disabled auto-merge
September 13, 2026 10:34
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
xtaskto keep local and Github runs in sync #24487. Both issues stay open.Rationale for this change
The three extended test suites run only in the merge queue, on release branches, and by manual dispatch. Their
cargo testcommands and environment variables exist only insideextended.yml. A developer who wants to reproduce a merge-queue failure must copy them by hand. This PR defines each command once inxtask, so local runs and GitHub Actions use the same definition.What changes are included in this PR?
cargo xtask ci step testgets three variants:extended,hash-collisions, andsqlite. Each variant reproduces the current CI invocation and sets only the environment that its suite needs. Thesqlitevariant sets noRUST_BACKTRACE, because its CI job skips the builder setup on purpose.extended.ymlcalls the three commands. Triggers, job IDs, job names, runners, containers, the clean working tree check, andcargo cleando not change.xtask/README.mddocuments the commands, their environment, prerequisites, and the parts of a CI job that a command does not reproduce.--explainprints the underlying command without running the suite:cargo xtask ci step test extended --explainWhat is the testing strategy for this PR?
xtask/src/ci_steps.rscover the exact command, working directory, and environment of each variant, plus rejection of an unknown variant.check_asf_yaml_status_checks.pypasses. All required check names are unchanged.xtaskon macOS. Theextended,hash-collisions, andsqlitesuites all passed with a clean working tree.The extended jobs skip ordinary pull request updates, so green PR checks do not exercise these commands. The merge queue does.
Are there any user-facing changes?
No. The GitHub CI behavior is the same. Developers get three new local commands.
🤖 Generated with Claude Code