Changing output base results in failed builds due to parsing the contents of the convenience symlinks

[adamporich]

Description of the problem / feature request:

When changing the output base. Bazel no longer recognizes the bazel-* symlinks as it's own and parses the contents resulting in build failues

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

Example repo at https://github.com/adamporich/simple-bazel-test just consists of a single passing test.

> bazel --output_base=/tmp/bazel_1 test //...
INFO: Invocation ID: bda33659-6dbb-4d03-9f8f-fb273b5bafa9
INFO: Analyzed target //:test (0 packages loaded, 0 targets configured).
INFO: Found 1 test target...
Target //:test up-to-date:
  bazel-bin/test
INFO: Elapsed time: 0.075s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
//:test                                                         (cached) PASSED in 0.0s

Executed 0 out of 1 test: 1 test passes.
INFO: Build completed successfully, 1 total action

> bazel --output_base=/tmp/bazel_2 test //...
Starting local Bazel server and connecting to it...
INFO: Invocation ID: bb24dd33-6bbb-4c47-a943-ed4bfc65a34a
ERROR: error loading package 'bazel-bazel_symlink_test/external/bazel_tools/tools/cpp': in /home/gimo/dev/bazel_symlink_test/bazel-bazel_symlink_test/external/bazel_tools/tools/cpp/compiler_flag.bzl: Label '//tools/cpp:toolchain_utils.bzl' is invalid because 'tools/cpp' is not a package; perhaps you meant to put the colon here: '//:tools/cpp/toolchain_utils.bzl'?
INFO: Elapsed time: 1.998s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (8 packages loaded)
FAILED: Build did NOT complete successfully (8 packages loaded)

What operating system are you running Bazel on?

Above output is from Linux but occurs on Windows as well

What's the output of bazel info release?

> bazel info release
INFO: Invocation ID: 4d53a63f-daf5-43a2-b0ff-f3ab4927c52c
release 4.2.1

Have you found anything relevant by searching the web?

#11875 is a similar issue but in this case we don't need a root level glob to trigger

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

I did try and use the https://docs.bazel.build/versions/4.2.1/command-line-reference.html#flag--experimental_convenience_symlinks option but it didn't seem to have an effect.

[dmivankov]

looks related #10653

[comius]

Hey, I think output paths are more concern of Configurability team? Or perhaps OSS? Please triage.

[katre]

I don't know if there's a good way to fix this, but I'll ask @gregestren to investigate when he's back.

[aiuto]

This is one of those things that just falls between the cracks. Not really Configurability or OSS.
I labeled it P3 on the grounds that it is not a common condition:

• most projects don't build //... while changing --output-base frequently
• you could just add bazel-* to .bazelignore

[brentleyjones]

you could just add bazel-* to .bazelignore

It doesn't support wildcards though, right? #7093

[aiuto]

Yes. It doesn't, but there are only 4 to add, so it's not that difficult to enumerate them all

…

On Fri, Sep 16, 2022 at 2:03 PM Brentley Jones ***@***.***> wrote: you could just add bazel-* to .bazelignore It doesn't support wildcards though, right? #7093 <#7093> — Reply to this email directly, view it on GitHub <#13951 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHHHARQ5MHNV4UNNR67ATV6SZAZANCNFSM5DTX6NJA> . You are receiving this because you commented.Message ID: ***@***.***>

[brentleyjones]

There are only 4 to add if you know the workspace name. One is based on the name of the directory the workspace is placed in, which can be different for each user. And that is the one that has caused me the most issues so far, because of the external inside of it.

[aiuto]

Then it would go in the .bazelrc for the workspace.

…

On Sun, Sep 18, 2022 at 6:16 PM Brentley Jones ***@***.***> wrote: There are only 4 to add if you know the workspace name. One is based on the name of the directory the workspace is placed in, which can be different for each user. — Reply to this email directly, view it on GitHub <#13951 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXHHHDD3DVSWYHDK2I57M3V66ICXANCNFSM5DTX6NJA> . You are receiving this because you commented.Message ID: ***@***.***>

[tpudlik]

Just ran into this issue, too. Should the documentation for --output_base mention that you need to add the bazel-* symlinks to .bazelignore to use this flag?

Are there any downsides to this workaround? It's not very clear to me what are the consequences of adding output directories to .bazelignore (I thought bazel would already ignore them by default!).

[aiuto]

Changing the docs seems like a good step.
It seems though, like bazel should ignore symlinks in ... processing, regardless of them being used in output_base.
Or, I think that the use bazel test //... is weird. Most code immediately gets more complex than that so you don't want the same options for every tree.
As a very rare user of --output_base, and a non-user of //..., I don't have enough flight time with the problem to offer good solutions.

[cameron-martin]

I labeled it P3 on the grounds that it is not a common condition:

most projects don't build //... while changing --output-base frequently
you could just add bazel-* to .bazelignore

This is a common thing for IDE extensions to do while syncing. It is recommened to use a different output base in the Bazel docs.

This looks like a duplication of #10653 anyway.

[iancha1992]

A fix for this issue has been included in Bazel 7.1.0 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.0rc2. Thanks!