Implement 3rd-party (envoy) proto generation mechanism by lidizheng · Pull Request #25272 · grpc/grpc

lidizheng · 2021-01-26T02:51:16Z

This PR improves our infrastructure code to support 3rd party proto dependencies, and allow them to generated C++ stubs via protoc compilation. It works for both Bazel and CMake.

The 3rd party proto libraries supported by this PR:

envoyproxy/data-plane-api
googleapis/googleapis
cncf/udpa
envoyproxy/protoc-gen-validate
census-instrumentation/opencensus-proto
ProtoBuf's well known protos (switched them to this path)

Bazel

For Bazel compilation, the general idea is letting Bazel treat envoy-api as a sub-repository. It's done by injecting a WORKSPACE file for it. But to avoid circular dependencies, we need to explicitly depend on transitive libraries. Most of the transitive libraries are already included in gRPC as Git submodules, except opencensus-proto which was needed by Envoy's opencensus.proto. The added grpc_deps are:

googleapis
re2
gazelle
opencensus-proto
protoc-gen-validate
io_bazel_rules_go (update required by protoc-gen-validate)

One extra setup is added for googleapis to WORKSPACE, so it exposes the APIs in a subset of languages instead of all of them.

~~Current version of re2 failed ASAN (see log). So, this PR disabled ODR check in ASAN (feel free to suggest other ways).~~

One caveat is the proto generation will fail on Windows RBE, since it doesn't have good Golang support (see log). The Golang tools is required by protoc-gen-validate which is a ProtoBuf plugin wrote by Envoy team, and it needs to be executed for every single Envoy proto files. CC @jtattermusch do you have more context about Golang on Windows RBE?

Overall, Bazel has generally good external library support. Follow the error log and fix the complains one-by-one, and it builds magically in the end.

ProtoBuf Inconsistent Path Problem

Without Bazel, we have to directly interact with protoc, which has some quirks that it is very picky about paths. One needs to find the right combination of working directory (pwd), import directory (-I), and import path (how one proto is meant to be imported). For example, let's say we have 2 proto files each in a different 3rd_party library:

# third_party/lib_a/a.proto
...
message NotImportant {}

# third_party/lib_b/b.proto

import "a.proto";
...

Proto file location	Current working directory	Expected Descriptor Name for "a.proto"	Generated Descriptor Path	How "b.pb.h" Imports "a.pb.h"	Generated "a.pb.h" Header Path
Untouched	.	descriptor_table_a_proto	descriptor_table_third_party_lib_a_a_proto ✗	#include "a.pb.h"	$OUTPUT/third_party/lib_a/a.pb.h ✗
Untouched	third_party	descriptor_table_a_proto	descriptor_table_lib_a_a_proto ✗	#include "a.pb.h"	$OUTPUT/lib_a/a.pb.h ✗
Both copied to project root	.	descriptor_table_a_proto	descriptor_table_a_proto ✓	#include "a.pb.h"	$OUTPUT/a.pb.h ✓
Only b.proto is copied to project root	.	descriptor_table_a_proto	descriptor_table_third_party_lib_a_proto ✗	#include "a.pb.h"	$OUTPUT/third_party/lib_a/a.pb.h ✗

As above, the ProtoBuf C++ generated code brutal-forcely translate the import line import "third_party/lib_a/a.proto"; to how its dependency headers should be imported, and what its dependency descriptor should be named. But it somehow generated descriptor name based on relative path. The inconsistent header file path is annoying but not blocking the build. However, the difference in descriptor name will cause the build to fail deterministically. This issue troubles many ProtoBuf adopters that it blocks people from using multiple repos to store proto files.

To make protoc work, we can simulate how it is intended to be used in Google, which is gathering the build metadata, find the expected import path, and rebuild the directories, like a monorepo, or like Bazel.

gRPC Buildgen

The core update is done within extract_metadata_from_bazel_xml.py:

Allow external library labels to be count as dependencies;
Treat external libraries as normal libraries, so the script can traverse to find all transitive dependencies;
Map external library Bazel file labels to actual file locations.

(By removing all the intermediate dependencies, we lost the needed information to build those files in order. But the script uses topological sort to create a workable building sequence... What's the rationale behind it?)

The buildgen code is kind of complex, to understand how it work, I polished part of them as I read. It modernized some function calls and added type annotations (not all). There was one logical change, which is move the pre-build logic from mako_renderer.py to generated_projects.py, because the pre-build logic isn't really using "mako" and will only be executed once, there is not much benefit to wrap it in a process pool.

Also, there were 2 tiny fixes: fixed the jobset.py output so it prints str instead of bytes, so when run_tests.py fails the result will be more readable; finally moved the PyYAML installation to sanity Docker container, sorry for delaying for so long.

CMake

The updated ProtoBuf generation logic is:

Create a cmake/build/protos directory (or /protos);
Copy proto files to cmake/build/protos;
Generate C++ files via protoc as needed.

Notably, in step 2, the copy is done by file(COPY instead of add_custom_command, so the proto files will always be copied regardless they were imported or not. This is not as elegant as per-file dependency, because updating the proto files could trigger a large scale rebuild. On the other hand, the per-file dependency is not hard to implemented (as follow). However, since we removed dependency information and I yet to grasp the essence of the build-order sort code, the PR currently uses the brutal-force-copy solution. (@jtattermusch Please help)

    add_custom_command(
        OUTPUT  <%text>${_gRPC_PROTO_SRCS_DIR}/${REL_DIR}</%text>
        COMMAND <%text>${CMAKE_COMMAND}</%text>
        ARGS    -E make_directory
                <%text>${_gRPC_PROTO_SRCS_DIR}/${REL_DIR}</%text>
        WORKING_DIRECTORY <%text>${CMAKE_CURRENT_SOURCE_DIR}</%text>
        VERBATIM)
    add_custom_command(
        OUTPUT  <%text>${_gRPC_PROTO_SRCS_DIR}/${IMPORT_PATH}</%text>
        COMMAND <%text>${CMAKE_COMMAND}</%text>
        ARGS    -E copy
                <%text>${CMAKE_CURRENT_SOURCE_DIR}/${FILE_LOCATION}</%text>
                <%text>${_gRPC_PROTO_SRCS_DIR}/${IMPORT_PATH}</%text>
        DEPENDS <%text>${CMAKE_CURRENT_SOURCE_DIR}/${FILE_LOCATION}</%text>
        WORKING_DIRECTORY <%text>${CMAKE_CURRENT_SOURCE_DIR}</%text>
        VERBATIM)

xDS End2End Test

I make our C++ xDS end2end test the final examination of this PR. I replaced all the xDS proto dependencies from our copied version under src/proto/grpc/testing/xds to their real, complete version. Since the protos were manually moved and trimmed, there were some inaccuracy in message naming.

Old Compilers

Current ProtoBuf library (v3.14.0) has a bug that prevents C++ generated code to build on gcc 4.9, gcc 5.3, clang 3.6, and clang 3.7. I filed an issue to them: protocolbuffers/protobuf#8240, but yet got any response. By upgrading to their head, we regain compatibility with gcc 4.9 and gcc 5.3, but ProtoBuf is still incompatible with clang 3.6 and clang 3.7...

This change is

lidizheng · 2021-02-04T03:10:10Z

@gnossen PTAL at the Bazel changes and the Python script updates.
@veblush PTAL at the CMake related changes and if I made some errors in "buildgen" scripts.

gnossen · 2021-02-04T18:50:40Z

Current version of re2 failed ASAN (see log). So, this PR disabled ODR check in ASAN (feel free to suggest other ways).

This isn't a workable solution. This will lead to nondeterminism and segfaults.

.gitmodules

bazel/grpc_deps.bzl

build_handwritten.yaml

third_party/envoy-api.WORKSPACE

tools/buildgen/_generate_projects.py

tools/buildgen/extract_metadata_from_bazel_xml.py

lidizheng

Thanks for the quick review, and catching the two re2 bug!

tools/buildgen/extract_metadata_from_bazel_xml.py

build_handwritten.yaml

.gitmodules

bazel/grpc_deps.bzl

tools/buildgen/_generate_projects.py

gnossen

LGTM on the Bazel changes. I can't speak for the Cmake changes though.

jtattermusch

There's some controversy here :-). Two main points:

let's split the PR into refactoring and cleanup
come up with a cleaner and more readable way to update tools/buildgen/extract_metadata_from_bazel_xml.py logic.

bazel/grpc_deps.bzl

build_autogenerated.yaml

build_handwritten.yaml

setup.cfg

tools/buildgen/_mako_renderer.py

tools/buildgen/extract_metadata_from_bazel_xml.py

templates/CMakeLists.txt.template

tools/buildgen/extract_metadata_from_bazel_xml.py

lidizheng

Thanks for the detailed review! PTALA @jtattermusch

bazel/grpc_deps.bzl

build_handwritten.yaml

templates/CMakeLists.txt.template

tools/buildgen/_mako_renderer.py

tools/buildgen/extract_metadata_from_bazel_xml.py

tools/buildgen/generate_build_additions.sh

tools/buildgen/_utils.py

tools/buildgen/plugins/generate_vsprojects.py

tools/buildgen/extract_metadata_from_bazel_xml.py

lidizheng · 2021-03-18T19:28:52Z

@jtattermusch PTALA. The changes have been rebased into this PR.

jtattermusch

Thanks for the rebase.
I reviewed and I think the overall approach looks ok, but some cleanup is still needed.
I'm particularly hesitant about he introduction of the "external_library" element in the build.yaml (since it goes against our past effort to remove stuff from build.yaml).

Other than that, I left a bunch of comments.

jtattermusch · 2021-03-17T15:42:42Z

test/distrib/cpp/run_distrib_test_cmake.bat


 @rem Just before installing gRPC, wipe out contents of all the submodules to simulate
 @rem a standalone build from an archive
-git submodule deinit --all --force


nit: why this change?

deinit leaves an empty folder, like third_party/udpa. But the submodule polling mechanism only works if the submodule's folder isn't exist. Alternatively, we can validate the integrity of each submodule but they will be much more complex, since the source archive contains no Git information.

tools/buildgen/extract_metadata_from_bazel_xml.py

jtattermusch · 2021-03-17T15:54:38Z

tools/buildgen/extract_metadata_from_bazel_xml.py

+    com_envoyproxy_protoc_gen_validate='third_party/protoc-gen-validate/',
+    opencensus_proto='third_party/opencensus-proto/src/')
+# The external repositories that we are currently able to support the metadata
+# extraction. We aim to support arbitrary external libraries in the long term.


"We aim to support arbitrary external libraries in the long term" - i'm not convinced that is actually what we want.

jtattermusch · 2021-03-17T16:06:53Z

tools/buildgen/extract_metadata_from_bazel_xml.py

+# extraction. We aim to support arbitrary external libraries in the long term.
+# This variable should be removed eventually.
+RE_MATCH_SUPPORTED_EXTERNAL_LIBS = re.compile(
+    f'^@({"|".join(EXTERNAL_LIB_LABEL_PATH_MAP.keys())}).*$')


I think constructing a huge regex from EXTERNAL_LIB_LABEL_PATH_MAP is actually quite fragile and hard to understand and it doesn't really buy you much (I'm pretty sure the speed gain from this in negligible since the number of source files we have is relatively small).
The keys are simply prefixes such as "@envoy_api" so you can match them with a simple for loop without needing complicated regexes constructed from dictionaries and the result is going to me more readable, with no noticeable speed impact.

Done. Make sense.

jtattermusch · 2021-03-19T14:15:26Z

src/xds-proto/gen_build_yaml.py

+    xml_tree = _fetch_raw_http_archives()
+    libraries = _parse_http_archives(xml_tree)
+    libraries.sort(key=lambda x: x.destination)
+    print(yaml.dump(dict(external_libraries=list(map(asdict, libraries)))))


also, you're ambitiously calling this the new entity external_library but it's unclear what is the future plan with it.
Is it intended to be only used for importing .proto files (in which case it should be e.g. external_proto_library) or are you somehow planning to use it for other libraries in the future as well? If so, since there's no detail no plan on that, it's unclear to me whether that would actually work or not and if it would be useful (more research would be needed).

I'm keeping it as external_library since we might move upb/xxhash into this list. WDYT?

CMakeLists.txt

jtattermusch · 2021-03-19T14:27:54Z

templates/CMakeLists.txt.template

+
+  % for external_library in external_libraries:
+  # Setup external proto libraray at ${external_library.destination}
+  if (NOT EXISTS <%text>${CMAKE_CURRENT_SOURCE_DIR}</%text>/${external_library.destination})


+1 for checking the submodule is already there and skipping the download if so. Perhaps we should add a comment that explains why exactly you're doing this?

Adding several comments, describing how the if condition works and what the download function is doing.

jtattermusch · 2021-03-19T14:32:11Z

templates/CMakeLists.txt.template

-  #     ``.proto`` files
+  #   ``FILE_LOCATION``
+  #     The relative path of the ``.proto`` file to the project root
+  #   ``IMPORT_PATH``


nit: you're calling this arg "import_path" which would suggest that it's a directory name, but from the generated files I can see it's the full file name (not just the path).

It's the ProtoBuf import path, where the source file itself thinks it should belong to. Feel free to suggest alternatives.

jtattermusch · 2021-03-19T14:35:49Z

tools/run_tests/sanity/check_bazel_workspace.py

    'opencensus_proto',
    'com_envoyproxy_protoc_gen_validate',
    'com_google_googleapis',
+    'com_github_cncf_udpa',


why is this under BAZEL_ONLY_DEPS? it seems there's a third_party/udpa submodule so it should be possible to check that the bazel dep and the submodule are at the same commit. Same for other "external proto" libraries.

Removed. TIL this is an exemption list, I thought it is adding extra checks.

lidizheng

Sorry for dragging this so long. Last 2 weeks I was trying to get fault injection/xDS config dump/admin interface done before the release cut.

I understand your concern about adding "external_library" element in the "build.yaml", but actually, with previous pattern the "external_library" is a transient "build.yaml" that will be placed in "/tmp". However, by moving the logic into "extract_metadata_from_bazel_xml.py", we are adding the new field to build_autogenerated.yaml.

Feel free to suggest alternative!

On a higher level, this PR will face a tough issue during import to google3 (same as #25762). None of the Envoy source code is accepted as Core component, but gRPC is a Core component. I guess the eventual result is that we will hide the xDS protos in google3 same as #25762. This requires further investigation.

lidizheng · 2021-03-19T17:15:27Z

tools/buildgen/extract_metadata_from_bazel_xml.py

 BuildDict = Dict[str, BuildMetadata]
 BuildYaml = Dict[str, Any]

+import build_cleaner


lidizheng · 2021-03-19T17:18:21Z

tools/buildgen/extract_metadata_from_bazel_xml.py

+
+PROJECT_ROOT = os.path.join(os.path.dirname(os.path.abspath(__file__)), '..',
+                            '..')
+os.chdir(PROJECT_ROOT)


Removed. With this line, I hoped this script can be invoked anywhere. But that seems like a useless feature.

lidizheng · 2021-03-19T17:19:07Z

tools/buildgen/extract_metadata_from_bazel_xml.py

+    com_envoyproxy_protoc_gen_validate='third_party/protoc-gen-validate/',
+    opencensus_proto='third_party/opencensus-proto/src/')
+# The external repositories that we are currently able to support the metadata
+# extraction. We aim to support arbitrary external libraries in the long term.


lidizheng · 2021-03-19T17:25:22Z

tools/buildgen/extract_metadata_from_bazel_xml.py

+# extraction. We aim to support arbitrary external libraries in the long term.
+# This variable should be removed eventually.
+RE_MATCH_SUPPORTED_EXTERNAL_LIBS = re.compile(
+    f'^@({"|".join(EXTERNAL_LIB_LABEL_PATH_MAP.keys())}).*$')


Done. Make sense.

lidizheng · 2021-03-19T17:37:29Z

test/distrib/cpp/run_distrib_test_cmake.bat


 @rem Just before installing gRPC, wipe out contents of all the submodules to simulate
 @rem a standalone build from an archive
-git submodule deinit --all --force


deinit leaves an empty folder, like third_party/udpa. But the submodule polling mechanism only works if the submodule's folder isn't exist. Alternatively, we can validate the integrity of each submodule but they will be much more complex, since the source archive contains no Git information.

lidizheng · 2021-03-30T21:43:01Z

templates/CMakeLists.txt.template

+
+  % for external_library in external_libraries:
+  # Setup external proto libraray at ${external_library.destination}
+  if (NOT EXISTS <%text>${CMAKE_CURRENT_SOURCE_DIR}</%text>/${external_library.destination})


Adding several comments, describing how the if condition works and what the download function is doing.

lidizheng · 2021-03-30T21:44:32Z

templates/CMakeLists.txt.template

-  #     ``.proto`` files
+  #   ``FILE_LOCATION``
+  #     The relative path of the ``.proto`` file to the project root
+  #   ``IMPORT_PATH``


It's the ProtoBuf import path, where the source file itself thinks it should belong to. Feel free to suggest alternatives.

lidizheng · 2021-03-30T21:52:40Z

templates/CMakeLists.txt.template

+  #   ``FILE_LOCATION``
+  #     The relative path of the ``.proto`` file to the project root
+  #   ``IMPORT_PATH``
+  #     The proto import path that itself expected to be placed in


Updated to:

# ``IMPORT_PATH`` # The proto import path that itself expected to be placed in. For # example, a "bar.proto" file wants to be imported as # `import "foo/bar.proto"`. Then we should place it under # "<ProtoBuf_Include_Path>/foo/bar.proto" instead of # "<ProtoBuf_Include_Path>/third_party/foo/bar.proto". This ensures # correct symbol being generated and C++ include path being correct. # More info can be found at https://github.com/grpc/grpc/pull/25762. #

lidizheng · 2021-03-30T21:58:49Z

templates/CMakeLists.txt.template

+    file(RELATIVE_PATH REL_FIL <%text>${_gRPC_PROTO_SRCS_DIR}</%text> <%text>${ABS_FIL}</%text>)
+    get_filename_component(REL_DIR <%text>${REL_FIL}</%text> DIRECTORY)
+    set(RELFIL_WE "<%text>${REL_DIR}/${FIL_WE}</%text>")
+    # copy the proto file to a centralized location


This is due to the import path issue I mentioned in the PR description.

The copy happened at configuration phase of the CMake building, and the generation happens in the actual building phase of the CMake building. This means before the first protoc command is invoked, all protos will be placed in the right location.

lidizheng · 2021-03-30T22:01:37Z

tools/buildgen/extract_metadata_from_bazel_xml.py

            # list since we want to avoid building sources that are already
            # built by our dependencies
            exclude_deps.update(bazel_rules[dep]['_TRANSITIVE_DEPS'])
+            exclude_deps.add(dep)


Reverted to your version.

I don't think it's worth either of our time to proof it's right or wrong. It's a trade off between CPU cycles and cleanness. I think both are correct as long as they generate correct result within acceptable time.

lidizheng · 2021-04-09T18:26:25Z

@jtattermusch The test should be green, and it is sync with master again. PTALA.

jtattermusch

LGTM, thanks for bearing with me and addressing all the comments I raised.

jtattermusch · 2021-04-12T10:54:42Z

cmake/download_archive.cmake

+set(_download_archive_TEMPORARY_DIR ${CMAKE_BINARY_DIR}/http_archives)
+file(MAKE_DIRECTORY ${_download_archive_TEMPORARY_DIR})
+
+# This is bascially Bazel's http_archive.


nit: bascially => basically

Done. Good finding!

jtattermusch · 2021-04-12T10:58:48Z

tools/run_tests/generated/tests.json

      "mac",
-      "posix",
-      "windows"
+      "posix"


nit: why this change? (also below in this file)

This is updating the admin_services_end2end_test test which uses Envoy proto on Windows, requiring to add Golang to our existing Windows RBE environment. But I haven't got time to experiment that effort yet.

jtattermusch · 2021-04-12T11:07:50Z

tools/buildgen/extract_metadata_from_bazel_xml.py

+                        src.replace(
+                            f"@{external_library_name}//",
+                            EXTERNAL_PROTO_LIBRARIES[external_library_name].
+                            proto_prefix).replace(':', "/"))


nit: inconsistent ' and " in replace(':', "/")

jtattermusch · 2021-04-12T11:12:54Z

tools/buildgen/extract_metadata_from_bazel_xml.py

+            # If this http archive is not one of the external proto libraries,
+            # we don't want to include it as a CMake target
+            continue
+        for url in http_archive["urls"]:


strictly speaking, duplicating the external_library entries when there's multiple URLs is not correct, but I can understand that it makes the logic in the CMakeLists.txt simpler to implement (but it also makes it a bit harder to understand).

Since the sha256 and strip_prefix for the mirrored urls always needs to be the same, I think it would be better for the external_library entity in the build_autogenerated.yaml to allow URL to be a list of URLs (this is not a problem at all for the yaml file). That way, the "metadata" in build_autogenerated.yaml would be more correct (because you'd keep the clear mapping between http_achives and "external_library" entries). The duplication download_archive rules can then be trivially done in CMakeLists.txt.template (and at that point it would be also easier to understand the logic behind it - you could even add an explanatory comment for cases where "urls" contains multiple entries.

Done. Updated the external_library to contain multiple URLs, and added comments if there are multiple download URLs for one library.

lidizheng

Thanks for the review! All comments addressed, PTALA. @jtattermusch

lidizheng · 2021-04-12T17:26:16Z

cmake/download_archive.cmake

+set(_download_archive_TEMPORARY_DIR ${CMAKE_BINARY_DIR}/http_archives)
+file(MAKE_DIRECTORY ${_download_archive_TEMPORARY_DIR})
+
+# This is bascially Bazel's http_archive.


Done. Good finding!

lidizheng · 2021-04-12T17:27:52Z

tools/run_tests/generated/tests.json

      "mac",
-      "posix",
-      "windows"
+      "posix"


This is updating the admin_services_end2end_test test which uses Envoy proto on Windows, requiring to add Golang to our existing Windows RBE environment. But I haven't got time to experiment that effort yet.

lidizheng · 2021-04-12T17:29:45Z

tools/buildgen/extract_metadata_from_bazel_xml.py

+                        src.replace(
+                            f"@{external_library_name}//",
+                            EXTERNAL_PROTO_LIBRARIES[external_library_name].
+                            proto_prefix).replace(':', "/"))


lidizheng · 2021-04-12T18:08:02Z

tools/buildgen/extract_metadata_from_bazel_xml.py

+            # If this http archive is not one of the external proto libraries,
+            # we don't want to include it as a CMake target
+            continue
+        for url in http_archive["urls"]:


Done. Updated the external_library to contain multiple URLs, and added comments if there are multiple download URLs for one library.

jtattermusch

Still LGTM. Thanks!

* Works for both CMake and Bazel * Instrument xds_end2end_test with protos from envoy-api * Fixed the Bazel repo naming with re2 * Refactor the build metadata compute algorithm * Now, in one pass, it will generate all the build metadata needed within this script, including the transitive deps, the sources/headers expanded without intermediate dependencies. * Temporarily remove the removal of third_party dependencies * Spin-off changes to sub PRs * Add a fetching mechanism for external proto libs * Accommodate Windows' CMake behavior difference * Allow CMakefile to fetch external library * The URL is parsed from grpc_deps * Allow multiple download URLs for extra stability

stale · 2021-07-13T01:57:43Z

This issue/PR has been automatically marked as stale because it has not had any update (including commits, comments, labels, milestones, etc) for 30 days. It will be closed automatically if no further update occurs in 7 day. Thank you for your contributions!

lidizheng · 2021-07-13T07:19:05Z

Still working on the internal parts of this PR, moving xDS protos into Core components.

lidizheng · 2022-01-24T19:14:29Z

It's been a year, the internal component change is about to complete.

lidizheng · 2022-03-25T01:21:54Z

We still want to remove the copied proto files. I have a rebased, all-in-one version in #29214. Learning from this PR, I hope this time I can make review less painful, so all code changes is split into:

markdroth · 2024-10-11T17:31:16Z

I think that almost all of the changes from this PR have been merged in other ways at this point, and I've just merged #37863 as a proof-of-concept that this works, so we no longer need this PR.

lidizheng added lang/c++ infra/buildgen area/build release notes: no Indicates if PR should not be in release notes labels Jan 26, 2021

lidizheng mentioned this pull request Jan 29, 2021

ASAN failed on re2 with odr-violation #25308

Closed

lidizheng added the kokoro:force-run label Feb 4, 2021

lidizheng marked this pull request as ready for review February 4, 2021 03:07

lidizheng requested review from apolcyn, gnossen, jtattermusch, nicolasnoble and veblush as code owners February 4, 2021 03:07

grpc-kokoro removed the kokoro:force-run label Feb 4, 2021

lidizheng assigned gnossen and veblush Feb 4, 2021

gnossen reviewed Feb 4, 2021

View reviewed changes

lidizheng added the kokoro:force-run label Feb 4, 2021

grpc-kokoro removed the kokoro:force-run label Feb 4, 2021

lidizheng force-pushed the xds-proto branch from 8497bb3 to ed00be1 Compare February 4, 2021 23:41

lidizheng commented Feb 4, 2021

View reviewed changes

gnossen approved these changes Feb 5, 2021

View reviewed changes

lidizheng assigned jtattermusch Feb 5, 2021

jtattermusch suggested changes Feb 8, 2021

View reviewed changes

lidizheng mentioned this pull request Feb 9, 2021

Implementation CSDS (xDS Config Dump) #25038

Merged

lidizheng commented Feb 11, 2021

View reviewed changes

lidizheng force-pushed the xds-proto branch from 29b4100 to 5d963ea Compare February 11, 2021 06:06

lidizheng requested a review from jtattermusch February 11, 2021 06:12

lidizheng force-pushed the xds-proto branch from 5d963ea to e924db4 Compare February 11, 2021 22:04

lidizheng requested a review from jtattermusch March 18, 2021 19:29

jtattermusch reviewed Mar 19, 2021

View reviewed changes

lidizheng commented Mar 30, 2021

View reviewed changes

jtattermusch approved these changes Apr 12, 2021

View reviewed changes

lidizheng commented Apr 12, 2021

View reviewed changes

jtattermusch approved these changes Apr 13, 2021

View reviewed changes

lidizheng force-pushed the xds-proto branch from b3cb590 to fccb428 Compare April 13, 2021 22:08

jtattermusch mentioned this pull request Apr 22, 2021

Run 2to3 on tools directory #26002

Merged

stale bot added the disposition/stale label Jul 13, 2021

lidizheng added disposition/never stale and removed disposition/stale labels Jul 13, 2021

lidizheng mentioned this pull request Mar 29, 2022

[xDS Proto] Enhence gRPC buildgen for 3rd party proto compilation #29254

Merged

lidizheng added a commit to lidizheng/grpc that referenced this pull request Apr 25, 2022

Same trick as grpc#25272, no_windows

9a3481d

This was referenced Apr 28, 2022

[xDS Proto] Add protoc-gen-validate back #29515

Closed

[xDS Proto] Remove Python's usage of copied proto files #29516

Merged

[xDS Proto] Remove C++'s usage of copied proto files #29474

Closed

jtattermusch removed their assignment Oct 3, 2023

markdroth closed this Oct 11, 2024

Conversation

lidizheng commented Jan 26, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Bazel

ProtoBuf Inconsistent Path Problem

gRPC Buildgen

CMake

xDS End2End Test

Old Compilers

Uh oh!

lidizheng commented Feb 4, 2021

Uh oh!

gnossen commented Feb 4, 2021

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lidizheng left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gnossen left a comment

Choose a reason for hiding this comment

Uh oh!

jtattermusch left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lidizheng left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lidizheng commented Mar 18, 2021

Uh oh!

jtattermusch left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lidizheng commented Jan 26, 2021 •

edited

Loading

lidizheng Mar 30, 2021 •

edited

Loading