`buildbuddy.yaml`: Set default --config

[Ivan Vučica]

In a toy personal project, I've set up a .bazelrc setting BuildBuddy flags if the passed --config is remote.

build:remote --remote_executor=grpcs://remote.buildbuddy.io
build:remote --host_platform=@buildbuddy_toolchain//:platform
build:remote --platforms=@buildbuddy_toolchain//:platform
...

These are good values to use, however, for now I'd still like to default to triggering a build locally (to make sure building without a remote cache and without RBE works fine as well).

While I could default to remote config in .bazelrc, or I could use buildbuddy.yaml to specify the entire bazel command, it might be nicer to allow specifying the --config as a separate field in buildbuddy.yaml avoiding having to override anything else (i.e. avoiding thinking about what specific commands to run, which is a major quality-of-life benefit obtained by using the GitHub app and not configuring too much CI).

[Siggi Simonarson]

Hey @ivucica, does specifying the --config=remote flag in your buildbuddy.yaml flag work like this? https://github.com/buildbuddy-io/buildbuddy/blob/master/buildbuddy.yaml#L52

[Ivan Vučica]

@siggisim I've indeed done that, but the preference would be to modify the default .yaml configuration even less. Or at least it was, until I realized the documentation seems to direct the reader to take the ~default .yaml and modify it.

--config seems similar to .bazelversion and similar, in the sense of "this is probably better kept out of .bazelrc". But, replacing the entire default buildbuddy.yaml if it isn't in use at that point also seems like possibly introducing the .yaml and its support for multiple workflows and multiple Bazel commands in a situation where it's not necessarily needed?

On the other hand: If this is indeed the intended way to modify --config, this bug might be a noop -- sorry for the noise.

[Son Luong Ngoc]

This is a nice suggestion that could simplify the bazel command in buildbuddy.yaml file for smaller use cases. However, I have spoken with folks who maintain big monorepos with convoluted .bazelrc file(s). Some even had to write a custom .bazelrc parser to render different configs as a graph to help untangle the mess.

So currently, relying on one --config= would only work up to a certain scale. With WIP proposals such as bazelbuild/bazel#18672, hopefully, Bazel flags management will get easier.

At least for the time being, I am in favor of using explicit flags under bazel_commands. Folks could consider leveraging YAML multi-lines syntax to help with managing the buildbuddy.yaml file easier.

For using a default config locally, we often set them in our own user.bazelrc file, which is optionally loaded at the end of .bazelrc file. You could find a templated version of that file here.

[Siggi Simonarson]

Going to close this for now, as the intended approach is to use the buildbuddy.yaml to set your config. Will keep this in mind though if / when we're considering improving the default buildbuddy.yaml file.