ci: split the release test gate into Java and Rust jobs - #469
Open
tinder-maxwellelliott wants to merge 1 commit into
Open
ci: split the release test gate into Java and Rust jobs#469tinder-maxwellelliott wants to merge 1 commit into
tinder-maxwellelliott wants to merge 1 commit into
Conversation
The release ran everything through one `bazel test //...` inside the reusable workflow's build job, so the Kotlin and Rust suites shared a runner and a fate: whichever failed first ended the run, and the other suite's verdict was never produced. v44.0.0 lost the whole release to "//tests:e2e_test TIMEOUT in 3600.0s" on that single job. Move the two language suites into `java-tests` (//cli/...) and `rust-tests` (//src/..., //tests/..., //tools/coverage/... and the two Rust lint gates). They run concurrently, each on its own runner with its own 6h GitHub job limit, and both gate the reusable workflow through `needs` -- so a release still requires both to be green, but a failure in one no longer suppresses the other's results. The Rust job names its packages recursively instead of going through the hand-maintained //:rust_tests suite, so a new test under //src or //tests is in the release gate whether or not it is added to that suite. What is left for the reusable workflow's build job is the Python and Go release tooling (//tools:all, //tools/go/...), which is fast enough not to warrant a third runner. The three commands together still cover every test in //...; the header comment records that invariant. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UCA8NTE34CAFHATYM6nU3a
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
2 participants
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.
The release ran everything through one
bazel test //...inside the reusable workflow's build job, so the Kotlin and Rust suites shared a runner and a fate: whichever failed first ended the run, and the other suite's verdict was never produced. v44.0.0 lost the whole release to "//tests:e2e_test TIMEOUT in 3600.0s" on that single job.Move the two language suites into
java-tests(//cli/...) andrust-tests(//src/..., //tests/..., //tools/coverage/... and the two Rust lint gates). They run concurrently, each on its own runner with its own 6h GitHub job limit, and both gate the reusable workflow throughneeds-- so a release still requires both to be green, but a failure in one no longer suppresses the other's results.The Rust job names its packages recursively instead of going through the hand-maintained //:rust_tests suite, so a new test under //src or //tests is in the release gate whether or not it is added to that suite.
What is left for the reusable workflow's build job is the Python and Go release tooling (//tools:all, //tools/go/...), which is fast enough not to warrant a third runner. The three commands together still cover every test in //...; the header comment records that invariant.