-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
api: add go proto generation script #8155
Conversation
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
Correct me if I'm wrong, but this will only generate If not, this basically forces all dependent golang code to use gogo. That would not work for grpc-go nor the goproto-based go-control-plane described in envoyproxy/go-control-plane#213. |
No, these are golang/protobuf protos as they are produced by bazel. The dependency on gogoproto is a vanity import due to the annotations. I don't think it does anything at runtime. We should just clean-up these annotations at some point. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks; I think this approach of relying the bazel build
and scraping is a reasonable way to go, we do it for docs.
It might be possible to make it even cleaner via a final genrule
that collects all the .go
in a zip
and then just do a copy+unzip here if you want to do more Bazel plumbing
/wait.
tools/api/generate_go_protobuf.py
Outdated
# go_out/envoy/config/bootstrap/v2 | ||
rule_dir, proto = rule[len("@envoy_api//"):].rsplit(':', 1) | ||
|
||
input_dir = os.path.join(bazel_bin, 'external', 'envoy_api', rule_dir, 'linux_amd64_stripped', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code is quite similar to https://github.com/envoyproxy/envoy/blob/master/docs/build.sh#L66. Is there a way to refactor to share, or maybe you can avoid reaching into amd64
named dirs somehow like we do for docs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
linux_amd64_stripped is specific to rules_go I think. It's not coming from bazel itself. I've tried to figure out how to get generated files with bazel query but eventually gave up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's due to compilation modes in go. It statically links everything, so it has to keep outputs in sub-directories https://github.com/bazelbuild/rules_go/blob/0303b3a69695e35940b09ddbf7a444bcc7fbefd4/go/private/mode.bzl.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you specify --strip=always
or -c fastbuild
when bazel build
is invoked in line 25? Otherwise the directory name is interfered by .bazelrc (e.g. I have -c dbg
in my bazelrc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's better to recommend running this script with empty --bazelrc=/dev/null
on linux amd64?
If you poke around the logic for the choice of the directory, it's pretty convoluted and interferes with msan/race/etc: https://github.com/bazelbuild/rules_go/blob/0303b3a69695e35940b09ddbf7a444bcc7fbefd4/go/private/mode.bzl#L135
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah an empty bazelrc works too but I think that ignores workspace .bazelrc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, -c fastbuild is better than ignoring workspace bazel rc.
tools/api/generate_go_protobuf.py
Outdated
os.makedirs(output_dir, 0o755) | ||
for generated_file in input_files: | ||
shutil.copy(generated_file, output_dir) | ||
os.chmod(os.path.join(output_dir, generated_file), 0o644) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could optionally just call rsync
here.
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
Re: final genrule: there's an experimental |
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
Mirrored stubs are available in https://github.com/envoyproxy/go-control-plane/tree/v2 |
This is great! Just wondering why you ended up placing the generated protos in go-control-plane instead of data-plane-api? |
go-control-plane has a CI system for validation and it is not read-only. It also sounded like less work than creating a brand new repository. |
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
tools/api/generate_go_protobuf.py
Outdated
|
||
# Each rule has the form @envoy_api//foo/bar:baz_go_proto. | ||
# First build all the rules to ensure we have the output files. | ||
if call(['bazel', 'build', '-c', 'fastbuild'] + go_protos) != 0: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just use subprocess.check_call?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, defer to @envoyproxy/api-shepherds
Let me extend this script to do mirroring as well. Would be nice to have a self-contained tool to both generate and publish. |
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
@kyessenov can this wait until @htuch gets back from vacation next week? He is better at Python and Bazel than I am. |
Sure, I'm refining the auto-sync script and will wait for Harvey to review it. |
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
This should be ready to after review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, a few comments/questions.
@@ -7,7 +7,7 @@ _PY_SUFFIX = "_py" | |||
_CC_SUFFIX = "_cc" | |||
_CC_EXPORT_SUFFIX = "_export_cc" | |||
_GO_PROTO_SUFFIX = "_go_proto" | |||
_GO_IMPORTPATH_PREFIX = "github.com/envoyproxy/data-plane-api/api/" | |||
_GO_IMPORTPATH_PREFIX = "github.com/envoyproxy/go-control-plane/" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this impact local development flows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This aligns the generated/bazel-internal build with the public bazel-less build, so I think it's an improvement.
Signed-off-by: Kuat Yessenov <[email protected]>
I'd like to keep this script simple and straightforward. Bash would be fine, but I can never really understand the control flow logic in it. I don't think we want a framework for the python scripts. This is a dangerous path to fall in (see istio's 5+ test frameworks for running scripts). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/wait
tools/api/generate_go_protobuf.py
Outdated
REPO_BASE = 'go-control-plane' | ||
BRANCH = 'master' | ||
MIRROR_MSG = 'Mirrored from envoyproxy/envoy @ ' | ||
USER_NAME = 'Kuat Yessenov' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have some kind of robo account here, e.g. what we do in https://github.com/envoyproxy/envoy/blob/master/ci/api_mirror.sh#L13.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a real account or just random email/username? I couldn't tell, and DCO didn't like it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switched to a robo account.
Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! LGTM
Adds a script to create a go module from the generated protobufs as part of envoyproxy#8151. The module appears to build with the following module declaration: module github.com/envoyproxy/data-plane-api/api go 1.12 require ( github.com/census-instrumentation/opencensus-proto v0.2.1 github.com/envoyproxy/protoc-gen-validate v0.1.0 github.com/gogo/protobuf v1.3.0 github.com/golang/protobuf v1.3.2 github.com/prometheus/client_model v0.0.0-20190812154241-14fe0d1b01d4 google.golang.org/genproto v0.0.0-20190819201941-24fa4b261c55 google.golang.org/grpc v1.23.0 ) Add CI automation to trigger the script after the merge to master in envoyproxy. Risk Level: low Testing: local build Docs Changes: none Release Notes: none Fixes envoyproxy#8151 Signed-off-by: Kuat Yessenov <[email protected]>
Adds a script to create a go module from the generated protobufs as part of envoyproxy#8151. The module appears to build with the following module declaration: module github.com/envoyproxy/data-plane-api/api go 1.12 require ( github.com/census-instrumentation/opencensus-proto v0.2.1 github.com/envoyproxy/protoc-gen-validate v0.1.0 github.com/gogo/protobuf v1.3.0 github.com/golang/protobuf v1.3.2 github.com/prometheus/client_model v0.0.0-20190812154241-14fe0d1b01d4 google.golang.org/genproto v0.0.0-20190819201941-24fa4b261c55 google.golang.org/grpc v1.23.0 ) Add CI automation to trigger the script after the merge to master in envoyproxy. Risk Level: low Testing: local build Docs Changes: none Release Notes: none Fixes envoyproxy#8151 Signed-off-by: Kuat Yessenov <[email protected]>
Adds a script to create a go module from the generated protobufs as part of envoyproxy#8151. The module appears to build with the following module declaration: module github.com/envoyproxy/data-plane-api/api go 1.12 require ( github.com/census-instrumentation/opencensus-proto v0.2.1 github.com/envoyproxy/protoc-gen-validate v0.1.0 github.com/gogo/protobuf v1.3.0 github.com/golang/protobuf v1.3.2 github.com/prometheus/client_model v0.0.0-20190812154241-14fe0d1b01d4 google.golang.org/genproto v0.0.0-20190819201941-24fa4b261c55 google.golang.org/grpc v1.23.0 ) Add CI automation to trigger the script after the merge to master in envoyproxy. Risk Level: low Testing: local build Docs Changes: none Release Notes: none Fixes envoyproxy#8151 Signed-off-by: Kuat Yessenov <[email protected]>
Signed-off-by: Kuat Yessenov [email protected]
Description:
Adds a script to create a go module from the generated protobufs as part of #8151.
The module appears to build with the following module declaration:
Add CI automation to trigger the script after the merge to master in envoyproxy.
Risk Level: low
Testing: local build
Docs Changes: none
Release Notes: none
Fixes #8151