--output_base in workspace causes infinite symlink when WORKSPACE uses load()

[clintharrison]

Description of the problem / feature request:

Bazel will recurse through the output base into the current workspace when --output_base is a directory in the workspace and the WORKSPACE file loads from a .bzl file in the workspace, causing an infinite symlink failure.

Feature requests: what underlying problem are you trying to solve with this feature?

We use --output_base=.bazel with .bazel in the .bazelignore file to keep the output base in the workspace to cache build output between CI steps.

This works well, unless we try to load() a repository rule from a .bzl file in the workspace. This requires us to use a @current_workspace//foo:path.bzl-style label. Doing so creates .bazel/external/current_workspace, which Bazel reports as an infinite symlink error.

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

Clone https://github.com/clintharrison/output-base-bug and run bazel --output_base=.bazel query //...

$ bazel --output_base=.bazel query //...                            
ERROR: infinite symlink expansion detected
[start of symlink chain]
/Users/charrison/code/tmp/output-base-bug/.bazel/external/output_base_bug
/Users/charrison/code/tmp/output-base-bug
[end of symlink chain]

What operating system are you running Bazel on?

macOS 10.13

What's the output of bazel info release?

release 0.21.0

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

It's also unclear why we need to use @current_workspace// labels here; in the toy example I linked above, it works to use a simple //foo:bar.bzl path, but that doesn't seem viable if we are writing Starlark rules that others want to include from their workspaces.

[clintharrison]

As a follow-up with the last comment, based on
bazel-contrib/rules_go#503 it seems it's done a workaround for #3115, which from my understanding is still broken for WORKSPACE files.

[praveenkanna]

Any update on this?

[aiuto]

Have you tried this workaround

mkdir $HOME/bazel_output_base
cd
ln -s $HOME/bazel_output_baze .bazel
add .bazel to .bazelignore

That seems to work for me.
I am not sure if this is a feature request or a bug. Allowing users to put the output_base back into the workspace is possibly an open-ended set of bugs down the path. I can see people wanting feedback loops from one build run to another.

[tfoggoa]

Hi @aiuto ,
I don't think this fixes the issue, because the content of build output would then be $HOME/bazel_output_base. We actually want the build output in a directory off the workspace root.
This is due to some historical reasons and using legacy build systems.
Also, we would not want multiple workspaces to share .bazel_output_base.
Thanks,
-Todd

[hlopko]

CC @aehlig / @irengrig

[hlopko]

@irengrig is this something that your managed directories can solve?

[hlopko]

Friendly ping :)

[iubica]

Running into the same problem. Our reason to place --output_base in the workspace is that we use Gilab, and, in order to pass build output from one Gitlab stage to another, we need the output_base to be a Gitlab artifact - which can only reside in the sandbox. Any solutions to this?

[iubica]

I solved my own problem listing the --output_base location in .bazelignore. The output_base can also be listed as a startup option in the .bazelrc file, to not have to repeat it manually in all bazel commands.

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.

[brentleyjones]

This is still an issue.