-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Querying "//..." fails if a top-level target exists and any external dependency can't be fetched #12497
Labels
P3
We're not considering working on this, but happy to review a PR. (No assignee)
team-Performance
Issues for Performance teams
type: bug
Comments
oquenchil
added
team-Performance
Issues for Performance teams
untriaged
type: bug
labels
Nov 18, 2020
meisterT
added
P3
We're not considering working on this, but happy to review a PR. (No assignee)
and removed
untriaged
labels
Nov 19, 2020
Interesting find. cc @zhengwei143 @Wyverald |
benjaminp
added a commit
to benjaminp/bazel
that referenced
this issue
Dec 1, 2020
…al workspaces. A packages path fragment is not unambiguous when external workspaces are involved. Fixes bazelbuild#12497.
benjaminp
added a commit
to benjaminp/bazel
that referenced
this issue
Dec 1, 2020
…al workspaces. A package's path fragment is not unambiguous when external workspaces are involved. Fixes bazelbuild#12497.
benjaminp
added a commit
to benjaminp/bazel
that referenced
this issue
Dec 4, 2020
…al workspaces. A package's path fragment is not unambiguous when external workspaces are involved. Fixes bazelbuild#12497.
benjaminp
added a commit
to benjaminp/bazel
that referenced
this issue
Dec 4, 2020
…al workspaces. A package's path fragment is not unambiguous when external workspaces are involved. Fixes bazelbuild#12497.
ulfjack
pushed a commit
to EngFlow/bazel
that referenced
this issue
Mar 5, 2021
…al workspaces. A package's path fragment is not unambiguous when external workspaces are involved. Fixes bazelbuild#12497. Closes bazelbuild#12595. PiperOrigin-RevId: 346048937
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
P3
We're not considering working on this, but happy to review a PR. (No assignee)
team-Performance
Issues for Performance teams
type: bug
Description of the problem / feature request:
If a workspace contains an external dependency that can't be fetched (upstream 404, shasum mismatch, whatever) then the presence of a build target in the top-level package will cause
bazel query
on//...
to fail.This happens regardless of whether the external dependency is in the transitive closure of the top-level target. As long as there is any top-level target, and in the workspace there is any target depending on the broken external dependency, then the query fails.
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Given the following workspace:
bazel query
fails:Removing the
gen_toplevel
target -- which has no relation to the failing dependency -- fixes the error, and letsbazel query
successfully return an empty result set:What operating system are you running Bazel on?
macOS, but I believe this bug is not platform-specific.
What's the output of
bazel info release
?Successfully reproduced with:
release 3.7.0
release 3.4.1
I have not yet tried reproducing at HEAD, or with an older release.
The text was updated successfully, but these errors were encountered: