Chiebot-Mirror
/
data-plane-api
mirror of https://github.com/envoyproxy/data-plane-api.git
8
0
Fork 0
Code Issues Projects Releases Wiki Activity
[READ ONLY MIRROR] Envoy REST/proto API definitions and documentation. (grpc依赖)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1342 Commits
2 Branches
0 Tags
18 MiB
Tag: Branch: Tree: bbc765afe5
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'bbc765afe5'
${ noResults }
data-plane-api/envoy/config/trace/v3/BUILD

17 lines
493 B
Raw Normal View History Unescape

api/build: automatically generate BUILD files. (#8506) This provides canonical BUILD formatting and puts protoxform in charge of being able to determine import paths, without having to worry about Bazel implications. Part of #8082. Risk level: Low Testing: tools/proto_sync.py, visual inspection of diffs. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ e53f40f0e5ccc84fca5cd350416fe0f2accf8229
5 years ago
# DO NOT EDIT. This file is generated by tools/proto_sync.py.
api/build: switch to only package level targets in API. (#8495) As part of #8082, we want to be able to (1) automatically generate BUILD files and (2) treat packages as atomic from a "upgrade / do not upgrade" decision perspective. This is simplified by having our BUILD targets at package granularity, since this is what the protoxform plugin operates on. This PR broadens the package-level treatment that was already introduced for Go in #8003 to Python and C++. This simplifies BUILD files significantly and opens the way to automated generation. There is some technical debt introduced, since all visibility controls have been removed. This is slated for reintroduction in https://github.com/envoyproxy/envoy/issues/8491. As a bonus (useful for BUILD file generation), also removed the inconsistency in BUILD package target naming for packages in envoy.api.* and envoy.type.*. E.g. //envoy/api/v2:v2 is now //envoy/api/v2:pkg. Risk level: Low (but this will break internal builds and require BUILD fixups to consuming projects). Testing: bazel test //test/... @envoy_api//... Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 4e858f17fe08224c9c089240908ccd0c518e01a7
5 years ago
load("@envoy_api//bazel:api_build_system.bzl", "api_proto_package")
api: clone v2[alpha] to v3alpha. (#8125) This patch establishes a v3alpha baseline API, by doing a simple copy of v2[alpha] dirs and some sed-style heuristic fixups of BUILD dependencies and proto package namespaces. The objective is provide a baseline which we can compare the output from tooling described in #8083 in later PRs, providing smaller visual diffs. The core philosophy of the API migration is that every step will be captured in a script (at least until the last manual steps), api/migration/v3alpha.sh. This script will capture deterministic migration steps, allowing v2[alpha] to continue to be updated until we finalize v3. There is likely to be significant changes, e.g. in addition to the work scoped for v3, we might want to reduce the amount of API churn by referring back to v2 protos where it makes sense. This will be done via tooling in later PRs. Part of #8083. Risk level: Low Testing: build @envoy_api//... Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 085d72b490c124a02849812798f5513a8df9ae72
5 years ago
licenses(["notice"]) # Apache 2
api: organize go_proto_libraries (#8003) Fixes #7982 Defines a package level proto library and its associated internal go_proto_library. Deletes all existing api_go_proto_library, api_go_grpc_library, and go_package annotations in protos (they are not required and pollute the sources). I deliberately avoided touching anything under udpa since it's being moved to another repository. Risk Level: low Testing: build completes Signed-off-by: Kuat Yessenov <kuat@google.com> Mirrored from https://github.com/envoyproxy/envoy @ d504fde0ffd97017d1ddff8caa9a3b46bba9ae48
5 years ago
api_proto_package(
deps = [
Tagging the rest of deprecated features unsupported. (#9636) This PR makes the following fatal by default: from cluster.proto: ORIGINAL_DST_LB, tls_context, extension_protocol_options from health_check.proto: use_http2 from route_components.proto: allow_origin regex, pattern, method, regex_match, value from http_connection_manager.proto: operation_name from trace.proto: HTTP_JSON_V1 from string.proto: regex Risk Level: Medium (who knows who is using them) Testing: test framework updates Docs Changes: n/a Release Notes: n/a Originally #8847 Signed-off-by: Alyssa Wilk <alyssar@chromium.org> Mirrored from https://github.com/envoyproxy/envoy @ 33100e8bbeca057e23d07e46e42c51376700f872
5 years ago
"//envoy/annotations:pkg",
api: freeze v3 API. (#9694) In which we convert every v3alpha reference to v3. In future revs of the stable API versioning policy, we will develop better tooling to support > 2 alpha and stable versions. For v3, it seems reasonable to just mv v3alpha to v3, since there should be no external consumers yet. Risk level: Low Testing: bazel test //test/..., CI. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 5248a4fb7d4c2a3d1fa151f944d3a63f6b7a06cf
5 years ago
"//envoy/config/core/v3:pkg",
api: link to previous message type package in API BUILD files. (#9210) * api: link to previous message type package in API BUILD files. We need to include the descriptors from the previous message version in the build. We opt to do this transitively; when you include v3 of a package, you get the v2 via a transitive dep. This should work based on alwayslink semantics for cc_library. The computation of the deps is based on the previous_message_type annotation, which will allow cross package migrations. Part of #8082. Risk level: Low Testing: Disabled ip_tagging v2 descriptor hack, observed version_integration_test. After the BUILD changes, this now passes again. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 7f8fb9509d3189819dd253e25ec76e939ae106e7
5 years ago
"//envoy/config/trace/v2:pkg",
X-Ray Localized Sampling (2/2) (#9167) Signed-off-by: Marco Magdy <mmagdy@gmail.com> Mirrored from https://github.com/envoyproxy/envoy @ 1a6b970f024e45746af3dc4977eec5239c64e3d3
5 years ago
"//envoy/config/trace/v2alpha:pkg",
update upda dependency (#9262) Signed-off-by: Lizan Zhou <lizan@tetrate.io> Mirrored from https://github.com/envoyproxy/envoy @ 4997d02fbf551e54bd569fd0e0ccbcf7e3362516
5 years ago
"@com_github_cncf_udpa//udpa/annotations:pkg",
api: clone v2[alpha] to v3alpha. (#8125) This patch establishes a v3alpha baseline API, by doing a simple copy of v2[alpha] dirs and some sed-style heuristic fixups of BUILD dependencies and proto package namespaces. The objective is provide a baseline which we can compare the output from tooling described in #8083 in later PRs, providing smaller visual diffs. The core philosophy of the API migration is that every step will be captured in a script (at least until the last manual steps), api/migration/v3alpha.sh. This script will capture deterministic migration steps, allowing v2[alpha] to continue to be updated until we finalize v3. There is likely to be significant changes, e.g. in addition to the work scoped for v3, we might want to reduce the amount of API churn by referring back to v2 protos where it makes sense. This will be done via tooling in later PRs. Part of #8083. Risk level: Low Testing: build @envoy_api//... Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 085d72b490c124a02849812798f5513a8df9ae72
5 years ago
"@opencensus_proto//opencensus/proto/trace/v1:trace_config_proto",
],
)