data-plane-api/envoy/extensions/transport_sockets/tls/v3/BUILD

# DO NOT EDIT. This file is generated by tools/proto_sync.py.

load("@envoy_api//bazel:api_build_system.bzl", "api_proto_package")

licenses(["notice"])  # Apache 2

api_proto_package(
    deps = [
        "//envoy/api/v2/auth:pkg",
        "//envoy/config/core/v3:pkg",
        "//envoy/type/matcher/v3:pkg",
        "@com_github_cncf_udpa//udpa/annotations:pkg",
    ],
)
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(`
config: breadcrumb annotations to infer earlier API message versions. (#9166) This PR avoids having to include an API type database in the Envoy build by introducing a message annotation option that allows Envoy to determine earlier corresponding message types via descriptor inspection. The ApiTypeDb is now ApiTypeOracle and utilizes these annotations. Risk level: Low Testing: Existing API and verison upgrade tests pass. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 297f7a73b3f93bccf8af73c0a555ae52bce6cecb 5 years ago			`deps = [`
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/api/v2/auth: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",`
			`"//envoy/type/matcher/v3: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",`
config: breadcrumb annotations to infer earlier API message versions. (#9166) This PR avoids having to include an API type database in the Envoy build by introducing a message annotation option that allows Envoy to determine earlier corresponding message types via descriptor inspection. The ApiTypeDb is now ApiTypeOracle and utilizes these annotations. Risk level: Low Testing: Existing API and verison upgrade tests pass. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 297f7a73b3f93bccf8af73c0a555ae52bce6cecb 5 years ago			`],`
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			`)`