fix(ci): stop failing PRs that touch only docker-host subtrees - #553
Merged
Conversation
A pull request changing only a docker-host subtree failed the required Bazel check with no failing job in the run. The single matrix row that ran passed. detect splits its output into two lanes. Such a change produces build-container=[] with docker-host=[<subtree>], but the build-container job was guarded on the combined `any` output rather than on its own matrix. `any` is true because a subtree was selected, so the job was asked to start with an empty matrix. GitHub cannot create a job from an empty matrix vector and resolves it to `failure` rather than `skipped`, so the aggregate result was failure while every row that existed succeeded. The gate then rejected it: the build-container branch accepted only `success`, while the docker branch immediately below already tolerated `skipped`. The asymmetry is what turned an empty lane into a red required check. Both halves are corrected. The job now guards on its own matrix, the way bazel-docker already does, and the gate tolerates `skipped` for it. That cannot hide a row that should have run: the job's condition is tied to its matrix being non-empty, so skipped means only that this lane had nothing to do, and the existing BAZEL_ANY check still catches the case where no subtree was selected. Co-authored-by: Balaji Ganesan <bganesan@nvidia.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Bazel workflow now skips the build-container job when its matrix is empty and treats that skipped state as valid during verification. ChangesBazel workflow gating
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
kristinapathak
approved these changes
Jul 29, 2026
balajinvda
enabled auto-merge
July 29, 2026 22:57
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.
Why
PR #548 failed its required Bazel check with nothing wrong in it. The run
contains three jobs: detect succeeded, the one matrix row that ran
(
bazel (cloud-tasks)) succeeded, and only the aggregate gate failed.detect emitted
selected 1 subtree(s): build-container=[] docker-host=[cloud-tasks].The
bazeljob is guarded onneeds.detect.outputs.any == 'true', the combinedcount across both lanes, but its matrix comes from
outputs.matrix, which wasempty.
anywas true because a subtree had been selected, so the job was askedto start with an empty matrix. GitHub cannot create a job from an empty matrix
vector and resolves it to
failure, notskipped-- soneeds.bazel.resultwas failure even though no row failed or could have.
The gate then rejected that: its build-container branch accepted only
success,while the docker branch three lines below already tolerated
skipped. Thatasymmetry is what turned an empty lane into a red required check.
This blocks any PR whose changes fall entirely in the docker-host lane.
What changed
Two lines, both needed.
The
bazeljob now guards onneeds.detect.outputs.matrix != '[]', its ownlane, exactly as
bazel-dockeralready guards onmatrix_docker != '[]'. Thatturns the empty case from
failureintoskipped.The gate then tolerates
skippedfor it, mirroring the docker branch. Fixingonly the guard would not help: the gate would still reject
skipped.This does not weaken the check. The job's condition is tied to its matrix being
non-empty, so
skippedcan only mean this lane had nothing to do -- it cannotmask a row that should have run. The existing
BAZEL_ANY != trueearly exitstill covers the case where no subtree was selected at all.
Customer Release Notes
Not customer visible.
Plan Summary
Not applicable.
Usage
Not applicable.
Testing
The diagnosis is from the failing run itself rather than inference: detect's log
shows the empty build-container lane, the job list shows the only row passing,
and the gate's own env dump shows
BAZEL_RESULT: failurewithBAZEL_ANY: true.The fix is exercised by this PR only insofar as it touches a workflow file. The
case it repairs is a docker-host-only change, which this is not. #548 is the
real reproduction: it should go green once it picks up main, since
pull_requestruns the workflow from the PR's own ref and cannot inherit thefix without a branch update.
Notes
Introduced with the change-aware matrix. It stayed latent because it needs a PR
whose entire change set lands in the docker-host lane, which until cloud-tasks
had active work was rare.
References
None
Related Merge Requests/Pull Requests
Unblocks #548.
Dependencies
None.
Summary by CodeRabbit