Use buf.build to generate go from proto

[mmorel-35]

I have used buf.build to regenerate the go files from the proto file .

This just needs to execute from root folder

go install github.com/bufbuild/buf/cmd/buf@latest 
buf generate --template buf.gen.go.yaml

I don’t have any knowledge on how bazel work to adapt the actual workflow but there is a documentation for this here :

https://buf.build/docs/build-systems/bazel

Signed-off-by: Matthieu MOREL [email protected]

[mmorel-35]

This is to publish proto as buf.build/cncf/xds in buf.build registry

[mmorel-35]

@phlax , what do you think about this ?

[phlax]

what do you think about this ?

i think its generally a good idea - i tried to introduce buf to this repo previously (#47) altho in that case just for linting

having said that i think it should be using bazel to install/run/build buf - my pr above covers at least the install part - i would be happy to help setting up a build target

cc @htuch @markdroth @adisuissa

[mmorel-35]

Can you contribute to my PR or shall include your modifications myself ?

[phlax]

lets get a general nod from repo maintainers before proceeding - i think the next step would be to land the buf/bazel installation, and then figure it out from there

[markdroth]

I don't know much about buf, but if the idea is to use that instead of protobuf to generate the go protos, we would need to make sure that the resulting generated code is compatible with protobuf, since there are existing go data planes using these protos with protobuf. @dfawley can speak to this w.r.t. grpc-go. @howardjohn may also want to weigh in from the Istio side.

[howardjohn]

I don't know much about buf, but if the idea is to use that instead of protobuf to generate the go protos, we would need to make sure that the resulting generated code is compatible with protobuf, since there are existing go data planes using these protos with protobuf. @dfawley can speak to this w.r.t. grpc-go. @howardjohn may also want to weigh in from the Istio side.

We use buf in Istio. I think its a great tool, especially if not using bazel (but may still be useful without bazel, I just haven't done the mix of the two; the alternative is a mess of makefiles generally). Its sort of like a build tool specific for proto, it is still invoking the same proto plugin binaries so the generation should be identical; this PR shows more changes since its also changing the versions of those binaries, but in general it should only change the comment (where it says which version of protoc was used for generation).

[htuch]

Makes sense to me, will defer to Go folks.

[mmorel-35]

Hi @htuch ,
Any news from the "Go folks" ?
Can @phlax start working on bazel based buf code generation and validation ?

By the way, following your comment

this PR shows more changes since its also changing the versions of those binaries

I tried to align the used version with the actually used for the generation but it seems like protoc-gen-validate was not in v1.0.2 as gomod says it

[phlax]

@mmorel-35 busy with other things atm - ill separate out the bazel/buf install into its own PR later or over w/end

[mmorel-35]

@phlax ,

busy with other things atm

It was more in the sense that, there is nothing blocking you on there point of view. Like if they are not interested there is no point to start working on it. Once this is not a blocker for them, you can start if and when ever you want. Sorry if this was misleading.

ill separate out the bazel/buf install into its own PR

I totally agree

[mmorel-35]

I aligned protoc-gen-validate with it's go.md version, see :
https://github.com/cncf/xds/pull/73/files#diff-340a0a599142950de3cef119fa68e93ef2350dbab23edaa3c7e561899e9ea399R6

[dfawley]

it is still invoking the same proto plugin binaries so the generation should be identical

Yes, this is the key; they still run our codegen, so this change seems more about "how the code generators are executed" vs. "what code is generated". So from gRPC-Go's perspective, this change is a no-op.