Description of the bug:
There is a rule in rules_apple called provisioning_profiles_repository. This rule has an attribute fallback_profiles of type Label. Passing a string the references the main repository results in that part of the label being discarded in the output BUILD file. For example, a string like:
...
fallback_profiles = @main-repo//provisioning/profiles:my_profiles
...
or
...
fallback_profiles = @//provisioning/profiles:my_profiles
...
results in a BUILD file like:
...
alias(
name = "fallback_profiles",
actual = "//provisioning/profiles:debug_profiles",
visibility = ["//visibility:public"],
)
...
which no longer has the @main-repo portion and results in a failure like:
/private/var/tmp/_bazel_codyv/34ff94ddc17314b0784f10abb6acba67/external/local_provisioning_profiles/BUILD.bazel:13:6: no such package '@local_provisioning_profiles//provisioning/profiles': BUILD file not found in directory 'provisioning/profiles' of external repository @local_provisioning_profiles
I've tracked it down to this commit: b21069f as being the cause.
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Change .bazelversion:
# .bazelversion
# b21069fd6f2440f90c57014b90063760223777e0 <- Fails
# cc55400e614e4e301244cc7c338ee3ea89424ce0 <- Works
test1.zip
run: bazel build //:test
In the "working" scenario, an error will be produced:
ERROR: /Users/codyv/Developer/bazelbuild/test1/BUILD:3:27: in local_provisioning_profile rule //:test:
/Users/codyv/Developer/bazelbuild/test1/test1.bzl:33:5: The following files have no generating action:
test.mobileprovision
and the [path/to/]external/my_profiles/BUILD.bazel will look like:
filegroup(
name = "profiles",
srcs = glob(["profiles/*.mobileprovision"], allow_empty = True),
visibility = ["//visibility:public"],
)
filegroup(
name = "empty",
srcs = [],
visibility = ["//visibility:public"],
)
alias(
name = "fallback_profiles",
actual = "@my-repo//provisioning/profiles:debug_profiles",
visibility = ["//visibility:public"],
)
and with the "Failure" hash, the error looks like:
ERROR: /private/var/tmp/_bazel_codyv/559ac1f1e133c637b2b59c5cce0ab6cc/external/my_profiles/BUILD.bazel:13:6: no such package '@my_profiles//provisioning/profiles': BUILD file not found in directory 'provisioning/profiles' of external repository @my_profiles. Add a BUILD file to a directory to mark it as a package. and referenced by '@my_profiles//:fallback_profiles'
and the [path/to/]external/my_profiles/BUILD.bazel will look like:
filegroup(
name = "profiles",
srcs = glob(["profiles/*.mobileprovision"], allow_empty = True),
visibility = ["//visibility:public"],
)
filegroup(
name = "empty",
srcs = [],
visibility = ["//visibility:public"],
)
alias(
name = "fallback_profiles",
actual = "//provisioning/profiles:debug_profiles",
visibility = ["//visibility:public"],
)
Notice the difference in the actual value.
Which operating system are you running Bazel on?
macOS 12.4
What is the output of bazel info release?
2022/07/18 15:50:18 Using unreleased version at commit b21069f
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
Using bazelisk at the specified hash
What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?
[email protected]:bazelbuild/bazel.git
03493b60baba5ca6780914715680d03791b39efc
03493b60baba5ca6780914715680d03791b39efc
Have you found anything relevant by searching the web?
b21069f is the commit that introduces this change of behavior.
Any other information, logs, or outputs that you want to share?
After manually adding in @my-repo or @ for the actual parameter in the BUILD.bazel file, then the expected behavior is shown.
Description of the bug:
There is a rule in
rules_applecalled provisioning_profiles_repository. This rule has an attributefallback_profilesof typeLabel. Passing a string the references the main repository results in that part of the label being discarded in the outputBUILDfile. For example, a string like:or
results in a
BUILDfile like:which no longer has the
@main-repoportion and results in a failure like:I've tracked it down to this commit: b21069f as being the cause.
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Change
.bazelversion:test1.zip
run:
bazel build //:testIn the "working" scenario, an error will be produced:
and the
[path/to/]external/my_profiles/BUILD.bazelwill look like:and with the "Failure" hash, the error looks like:
and the
[path/to/]external/my_profiles/BUILD.bazelwill look like:Notice the difference in the
actualvalue.Which operating system are you running Bazel on?
macOS 12.4
What is the output of
bazel info release?2022/07/18 15:50:18 Using unreleased version at commit b21069f
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.Using bazelisk at the specified hash
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD?Have you found anything relevant by searching the web?
b21069f is the commit that introduces this change of behavior.
Any other information, logs, or outputs that you want to share?
After manually adding in
@my-repoor@for theactualparameter in theBUILD.bazelfile, then the expected behavior is shown.