Dedicate some part of the Build Event Protocol to extensions

[crydell-ericsson]

Description of the feature request:

Add some safe way of making non-upstream extensions of the Build Event Protocol, e.g. by adding protobuf.Any fields to the BuildEvent and BuildEventId messages.

Which category does this issue belong to?

No response

What underlying problem are you trying to solve with this feature?

We have a fork of Bazel that produces data that we want to collect via the Build Event Protocol. This data comes from custom features that are not present upstream, so the changes to the BEP cannot reasonably be pushed upstream. However, we still want to be able to continue to uplift our fork to the latest Bazel version.

If we were to arbitrarily add new fields to the BEP protobuffer definition, there's a risk that the field numbers of these fields would collide with new upstream fields. These collisions would require us to either change the number of our own field, which would make older versions of our fork incompatible, or change the number of the new upstream field, which would make it incompatible with any third-party consumers of the BEP.

One way of working around this issue would be to pick large numbers for extension fields and hope that they are never used upstream. While this would most likely work for sufficiently large numbers, we think it's preferable to have an approach that is guaranteed to work.

We think it would be good to dedicate some part of the BEP protobuffer definition to extensions of the protocol. One way of doing this might be to add new fields with the protobuf.Any type in the payload of BuildEvent and the id of BuildEventId. This should allow us to use the BEP to send custom events with arbitrary multiplicity.

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

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

No response