fetch no longer works for targets ending in ...

[jfirebaugh]

Description of the bug:

Bazel 7.1.0 has a breaking change to bazel fetch. It's no longer possible to fetch target labels ending in ....

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

$ bazel fetch @go_sdk//...  
INFO: Analyzed 59 targets (0 packages loaded, 0 targets configured).
INFO: Found 59 targets...
ERROR: Error doing post analysis query: Evaluation failed: Unable to load package '[/private/var/tmp/_bazel_john/67beefda950d56283b98d96980e6e332/external/go_sdk]/[]' because package is not in scope. Check that all target patterns in query expression are within the --universe_scope of this query.
INFO: Elapsed time: 0.543s, Critical Path: 0.00s
INFO: 0 processes.
ERROR: Build did NOT complete successfully
ERROR: Fetching some target dependencies for deps(@go_sdk//...) failed, but --keep_going specified.  Ignoring errors

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

release 7.1.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

n/a

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

Yes

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[Wyverald]

Context: 7.1.0 we switched bazel fetch X from performing a bazel query deps(X) to bazel cquery deps(X). Looks like cquery somehow requires --universe_scope for target patterns with ...? I wonder if we could just specify a default universe scope of "everything" and be done with it.

cc @meteorcloudy; @haxorz (for --universe_scope insights); @gregestren (for cquery insights)

[Wyverald]

@bazel-io fork 7.1.1

[Wyverald]

If this is nontrivial to fix, we might need to roll back the query->cquery change. It's had too many unforeseen backward incompatibilities.

[SalmaSamy]

I think widening the scope of the query is the solution, but I am not sure making the default scope 'everything' is a good idea as it may make fetch very slow and would also fetch more than needed in other cases.

I guess this issue is common with external repos? so maybe something like: if the target is external, add the repo to the query universe-scope?

[meteorcloudy]

What is the default --universe_scope when doing bazel fetch @go_sdk//...? Is there a reproducible case? I tried locally to fetch some simple repos like @platforms//... and it worked.

[meteorcloudy]

OK, I can reproduce with rules_go:

pcloudy@pcloudy-macbookpro3:~/workspace/rules_go (master)
$ bazel fetch @go_sdk//...
Starting local Bazel server and connecting to it...
INFO: Invocation ID: 7ae0f9bf-4a35-4f08-93ff-af1c3fe85342
INFO: Options provided by the client:
  Inherited 'common' options: --isatty=1 --terminal_columns=164
INFO: Reading rc options for 'fetch' from /Users/pcloudy/workspace/rules_go/.bazelrc:
  Inherited 'common' options: --enable_platform_specific_config --noexperimental_enable_bzlmod
INFO: Reading rc options for 'fetch' from /Users/pcloudy/.bazelrc:
  Inherited 'build' options: --verbose_failures --announce_rc --disk_cache=/tmp/bazel_disk_cache --repository_cache=/tmp/bazel_repository_cache
INFO: Reading rc options for 'fetch' from /Users/pcloudy/workspace/rules_go/.bazelrc:
  Inherited 'test' options: --test_output=errors
INFO: Reading rc options for 'fetch' from /Users/pcloudy/.bazelrc:
  Inherited 'test' options: -k --test_output=errors
INFO: Analyzed 59 targets (10 packages loaded, 9364 targets configured).
INFO: Found 59 targets...
ERROR: Error doing post analysis query: Unable to load package '[/private/var/tmp/_bazel_pcloudy/47a70700a1df689551e6f1da93464795/external/go_sdk]/[]' because package is not in scope. Check that all target patterns in query expression are within the --universe_scope of this query.
INFO: Elapsed time: 15.051s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions
INFO: All external dependencies for these targets fetched successfully.

[SalmaSamy]

@meteorcloudy The default should be the targets parsed from the query expression, basically the same targets you're trying to fetch.
So for '@go_sdk//...' it should actually be '@go_sdk//...' which should work! but according to this, it may still not work :|

[Wyverald]

I dug around a bit with help from @gregestren. It appears that cquery itself doesn't support this query (i.e. bazel cquery @go_sdk//... fails with the exact same error message). It's unclear to me what value of --universe_scope will make the query succeed.

In the interest of not blocking 7.1.1 further, I'm going to revert the original change in 7.1.0.

[iancha1992]

A fix for this issue has been included in Bazel 7.1.1 RC2. Please test out the release candidate and report any issues as soon as possible.
If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=7.1.1rc2. Thanks!

[meteorcloudy]

I wonder why we have to use cquery? Can we implement bazel fetch as bazel build --nobuild <target> instead?

[SalmaSamy]

I wonder why we have to use cquery? Can we implement bazel fetch as bazel build --nobuild <target> instead?

Tried that and it seems to work :)

[brentleyjones]

@bazel-io flag

[iancha1992]

@bazel-io fork 7.2.0