Summary
bcr_presubmit.py's prepare_test_module_repo runs bazel vendor
with USE_BAZEL_VERSION=latest, regardless of the Bazel version
specified in the module's presubmit.yml matrix. This causes module
graph resolution failures for modules whose transitive deps are
compatible with their declared Bazel version but not with latest.
Reproducer
A module declares bazel: ["8.x"] in presubmit.yml and depends on
[email protected]. grpc declares [email protected] (compatibility
level 2). On Bazel 9, bazel_tools bundles [email protected]
(compatibility level 3), so module resolution fails:
ERROR: Error computing the main repository mapping: [email protected]
depends on [email protected] with compatibility level 2, but
bazel_tools@_ depends on [email protected] with compatibility
level 3 which is different
This doesn't happen on Bazel 8 (whose bazel_tools doesn't depend
on rules_swift at all), which is the version the module actually
targets.
Hit while submitting [email protected] (#8183).
Failing CI run: https://buildkite.com/bazel/bcr-presubmit/builds/32035
Proposed fix
Use the Bazel version from the presubmit.yml matrix for the vendor
step, not latest. The vendor step resolves the module graph, which
is version-sensitive — using a different Bazel version than the build
defeats the purpose of the matrix.
Workaround
Submit a BCR patch for the transitive dep (grpc) that bumps
rules_swift, even though the module itself works fine on the declared
Bazel version.
Summary
bcr_presubmit.py'sprepare_test_module_reporunsbazel vendorwith
USE_BAZEL_VERSION=latest, regardless of the Bazel versionspecified in the module's
presubmit.ymlmatrix. This causes modulegraph resolution failures for modules whose transitive deps are
compatible with their declared Bazel version but not with
latest.Reproducer
A module declares
bazel: ["8.x"]inpresubmit.ymland depends on[email protected]. grpc declares[email protected](compatibilitylevel 2). On Bazel 9,
bazel_toolsbundles[email protected](compatibility level 3), so module resolution fails:
This doesn't happen on Bazel 8 (whose
bazel_toolsdoesn't dependon
rules_swiftat all), which is the version the module actuallytargets.
Hit while submitting
[email protected](#8183).Failing CI run: https://buildkite.com/bazel/bcr-presubmit/builds/32035
Proposed fix
Use the Bazel version from the presubmit.yml matrix for the vendor
step, not
latest. The vendor step resolves the module graph, whichis version-sensitive — using a different Bazel version than the build
defeats the purpose of the matrix.
Workaround
Submit a BCR patch for the transitive dep (grpc) that bumps
rules_swift, even though the module itself works fine on the declared
Bazel version.