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?
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
andBuildEventId
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
ofBuildEvent
and theid
ofBuildEventId
. 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
returnsdevelopment 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