Explicit command line does not include label flags

[tpudlik]

The "Explicit command line" section of the invocation does not include label flags, even when those were in fact manually provided on the command line.

Example invocation: https://app.buildbuddy.io/invocation/a4c4ef57-d047-462c-8dc8-93e41d49f0b0. The explicit command line is stated to be,

bazel test //pw_bytes:byte_builder_test --subcommands=pretty_print --config=buildbuddy --platforms=//pw_unit_test:googletest_platform --toolchain_resolution_debug=@bazel_tools//tools/cpp:toolchain_type

But in fact, I provided a couple more flags on the command line when generating this invocation:

--//pw_unit_test:backend=//pw_unit_test:googletest
--//pw_unit_test:main=@@com_google_googletest//:gtest_main

These flags are listed in the "canonical command line", but they should be part of the "explicit command line", too!

[siggisim]

Hey @tpudlik - thanks for the report! If you take a look at the Raw tab https://app.buildbuddy.io/invocation/a4c4ef57-d047-462c-8dc8-93e41d49f0b0#raw at the optionsParsed event we get directly from Bazel - it looks like this:

"explicitCmdLine": [
            "--subcommands=pretty_print",
            "--config=buildbuddy",
            "--platforms=//pw_unit_test:googletest_platform",
            "--toolchain_resolution_debug=@bazel_tools//tools/cpp:toolchain_type"
        ],

which doesn't contain the label flags you mentioned. This is the field we use to render that explicit command line section in the UI. I wonder if it'd be worth filing a https://github.com/bazelbuild/bazel bug to properly populate that build event.

Maybe @fmeum or @sluongng have some ideas on how easy of a fix this would be.

[sluongng]

Fabian might know more than I do, but I think Starlark-defined flags are handled separately from Bazel's java-native defined flags.

https://cs.opensource.google/bazel/bazel/+/b3cc928b4b1bdff0182a9a9a31d409fd6515a2af:src/main/java/com/google/devtools/common/options/OptionsParserImpl.java;l=709-712

So the OptionParsed event might have happened before any of the Starlark flags were processed in Bazel. The "canonical" StructuredCommandLine event, which comes soon after, is a better basis for the Starlark flags.

I think we could add a (?) tooltips on our BuildBuddy UI to help explain these event categories better though 🤔

[fmeum]

They are handled separately, but they would be available in GotOptionsEvent, where they could be added to the unstructured BES list of options. I will send a PR to Bazel.

[fmeum]

@tpudlik Solving this properly requires quite a bit more effort than I expected. Could you file an issue on the Bazel repo first?

[tpudlik]

I'm happy to file a bug on the Bazel side. The reason I thought this might be a BuildBuddy specific issue is that BTX treats label flags correctly (see "original" in the "Command lines" section of https://btx.cloud.google.com/invocations/50854557-b7e2-46a4-97c3-8d997e6b1da1/details).

[siggisim]

We could potentially render original rather than explicit - not sure what other trade-offs that has though

[siggisim]

Looks like we already render what bazel sends us as "original command line" - but that contains a bunch of junk:

[tpudlik]

Ah, I missed the difference between original and explicit. Filed bazelbuild/bazel#23514 on the Bazel side.