Cannot run remote-worker when --disk_cache option is on .bazelrc

[or-shachar]

Description of the problem / feature request:

I have a configured disk_cache in my .bazelrc but I have a job in my CI that needs to run it using remote worker.
This is what I have in my .bazrlrc

//... other generic options
test --disk_cache=/tmp/bazel

This is the command I'm running:

bazel --bazelrc=.bazelrc.remote test  -k \ 
--config=remote \
--config=results \
--disk_cache=""  \
--project_id=*** \
--remote_instance_name=*** \
      //...

(.bazelrc.remote follows the example from here with the command
import %workspace%/.bazelrc)

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

I need the simple blob cache when running locally. Seems like combining that option with remote bazelrc makes the build fail with

ERROR: 'remote' is an invalid value for remote spawn strategy. Valid values are: linux-sandbox, local, processwrapper-sandbox, sandboxed, standalone, worker

Even after upgrading to bazel 0.14.1 with the following fix: bazelbuild/bazel@6b16352
And overriding that option with --disk_cache="" I still get the same message.

The error message in general is confusing and contradicts the example here.

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

1. create a sample bazel repository with .bazelrc with test disk_cache=/tmp/bazel
2. add .bazelrc.remote the imports the base .bazelrc (like described above)
3. Run bazel with remote workers (with the example above)

What operating system are you running Bazel on?

linux - CentOS

What's the output of bazel info release?

bazel 0.14.1

+ bazel info
Starting local Bazel server and connecting to it...
.........
character-encoding: file.encoding = ISO-8859-1, defaultCharset = ISO-8859-1
command_log: /home/builduser/.cache/bazel/_bazel_builduser/fb5c53da8fa139601cca52ba21545fd4/command.log
committed-heap-size: 296MB
gc-count: 5
gc-time: 56ms
install_base: /home/builduser/.cache/bazel/_bazel_builduser/install/e584f4223170558586344d31921e7766
java-home: /home/builduser/.cache/bazel/_bazel_builduser/install/e584f4223170558586344d31921e7766/_embedded_binaries/embedded_tools/jdk/jre
java-runtime: OpenJDK Runtime Environment (build 1.8.0_163-b01) by Azul Systems, Inc.
java-vm: OpenJDK 64-Bit Server VM (build 25.163-b01, mixed mode) by Azul Systems, Inc.
max-heap-size: 3514MB
package_path: %workspace%
release: release 0.14.1
repository_cache: /home/builduser/.cache/bazel/_bazel_builduser/cache/repos/v1server_pid: 10769
used-heap-size: 97MB

Have you found anything relevant by searching the web?

bazelbuild/bazel@6b16352
bazelbuild/bazel#5234

[nlopezgi]

Hi Or,
This does seem to indeed be an issue we had not seen before. However, this repo is not the right location to report issues related to rbe. Please send an email to rbe-support@ with any issues related to this service in the future. I will send email to rbe-support with this info and cc you. Closing.

[jmillikin-stripe]

@or-shachar Can you run Bazel with --announce_rc and post what it prints out? It should report that the --disk_cache flag is being overridden.

[or-shachar]

Thanks @jmillikin-stripe - will send in the email! Seems like ti doesn't print any of the options given to the command line, though

[ulfjack]

The --announce_rc flag does not include command-line options (maybe it should?). The remote strategy is only available if you don't use caching. If you enable remote caching, you should remove the --*_strategy=remote options. This means that your build will start to run with local sandboxing; if you don't want that, then you can set the flags to =standalone instead.

[ulfjack]

(I agree that this is confusing, FWIW. Sorry about that.)

[ulfjack]

Ok, I'm not sure if we should keep this open to make the flags and error messages more understandable or close since the title refers to a specific issue that was solved in 0.14.1 with the --disk_cache="" flag.

[nlopezgi]

Created bazelbuild/bazel#5401 in bazel repo (this got filed to bazel-toolchains and followup would get lost here)