Bazel 4.2.0 introduced a regression in the handling of Starlark flags: In a transition, the value of such a flag cannot be read if the flag is referred to as @repository_name//:flag_name instead of //:flag_name, which as far as I know is required for that transition to be usable by other workspaces. Reading the flag does not work even if it is set via both --@repository_name//:flag_name and --//:flag-name on the commandline.
I noticed this while working on rules_fuzzing, whose tests no longer pass with Bazel 4.2.0. Usage of rules_fuzzing by other workspaces does not seem to be affected.
I created a reproducer that prints
regressedwith
not_regressed with
- Bazel 4.0.0
- Bazel 4.1.0
- Bazel 5.0.0-pre.20210810.4
- Bazel 4.2.0 with 80c59de reverted
Unfortunately 98d376f cannot be cleanly cherry-picked on top of Bazel 4.2.0 by itself, so reverting 80c59de appears to be the safest way to mitigate this regression.
Originally posted by @fmeum in #13558 (comment)
Bazel 4.2.0 introduced a regression in the handling of Starlark flags: In a transition, the value of such a flag cannot be read if the flag is referred to as
@repository_name//:flag_nameinstead of//:flag_name, which as far as I know is required for that transition to be usable by other workspaces. Reading the flag does not work even if it is set via both--@repository_name//:flag_nameand--//:flag-nameon the commandline.I noticed this while working on rules_fuzzing, whose tests no longer pass with Bazel 4.2.0. Usage of
rules_fuzzingby other workspaces does not seem to be affected.I created a reproducer that prints
regressedwithnot_regressedwithUnfortunately 98d376f cannot be cleanly cherry-picked on top of Bazel 4.2.0 by itself, so reverting 80c59de appears to be the safest way to mitigate this regression.
Originally posted by @fmeum in #13558 (comment)