Transitions cannot read Starlark flags as @repository_name//:flag_name in 4.2.0
#13890
Comments
|
Investigating now. Please also file an issue at https://github.com/bazelbuild/continuous-integration/issues/new/choose to have rules_fuzzing added to our downstream CI, to prevent this happening in the future. |
katre
added a commit
to katre/bazel
that referenced
this issue
Aug 23, 2021
Fixes bazelbuild#13890. This reverts commit 80c59de.
|
This will be fixed in 4.2.1. |
fmeum
added a commit
to fmeum/rules_go
that referenced
this issue
Dec 19, 2021
The Label constructor can be used to transform a label string such as
@io_bazel_rules_go//foo:bar into the canonical label referencing this
target from the repository in which it is called.
For example, `str(Label("@io_bazel_rules_go//foo:bar"))` returns
`"@io_bazel_rules_go//foo:bar"` if rules_go is used as an external
repository from another main workspace, but returns `"//foo:bar"` when
rules_go is the main repository (e.g., when running the tests in the
CI).
This requires raising the minimum version of Bazel from 4.2.0 to 4.2.1
due to bazelbuild/bazel#13890.
fmeum
added a commit
to fmeum/rules_go
that referenced
this issue
Dec 20, 2021
The Label constructor can be used to transform a label string such as
@io_bazel_rules_go//foo:bar into the canonical label referencing this
target from the repository in which it is called.
For example, `str(Label("@io_bazel_rules_go//foo:bar"))` returns
`"@io_bazel_rules_go//foo:bar"` if rules_go is used as an external
repository from another main workspace, but returns `"//foo:bar"` when
rules_go is the main repository (e.g., when running the tests in the
CI).
This requires raising the minimum version of Bazel from 4.2.0 to 4.2.1
due to bazelbuild/bazel#13890.
fmeum
added a commit
to fmeum/rules_go
that referenced
this issue
Dec 20, 2021
The Label constructor can be used to transform a label string such as
@io_bazel_rules_go//foo:bar into the canonical label referencing this
target from the repository in which it is called.
For example, `str(Label("@io_bazel_rules_go//foo:bar"))` returns
`"@io_bazel_rules_go//foo:bar"` if rules_go is used as an external
repository from another main workspace, but returns `"//foo:bar"` when
rules_go is the main repository (e.g., when running the tests in the
CI).
This requires raising the minimum version of Bazel from 4.2.0 to 4.2.1
due to bazelbuild/bazel#13890.
fmeum
added a commit
to fmeum/rules_go
that referenced
this issue
Dec 20, 2021
The Label constructor can be used to transform a label string such as
@io_bazel_rules_go//foo:bar into the canonical label referencing this
target from the repository in which it is called.
For example, `str(Label("@io_bazel_rules_go//foo:bar"))` returns
`"@io_bazel_rules_go//foo:bar"` if rules_go is used as an external
repository from another main workspace, but returns `"//foo:bar"` when
rules_go is the main repository (e.g., when running the tests in the
CI).
This requires raising the minimum version of Bazel from 4.2.0 to 4.2.1
due to bazelbuild/bazel#13890.
achew22
pushed a commit
to bazel-contrib/rules_go
that referenced
this issue
Dec 28, 2021
The Label constructor can be used to transform a label string such as
@io_bazel_rules_go//foo:bar into the canonical label referencing this
target from the repository in which it is called.
For example, `str(Label("@io_bazel_rules_go//foo:bar"))` returns
`"@io_bazel_rules_go//foo:bar"` if rules_go is used as an external
repository from another main workspace, but returns `"//foo:bar"` when
rules_go is the main repository (e.g., when running the tests in the
CI).
This requires raising the minimum version of Bazel from 4.2.0 to 4.2.1
due to bazelbuild/bazel#13890.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to 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)
The text was updated successfully, but these errors were encountered: