chore: Split proto breaking change detection config (#2212)

We generally care about preserving JSON compatibility for protobuf
files, but for some files, where we only use pure gRPC, we only
care about preserving wire compatibility.

Split our buf breaking invocation into two invocations, one that checks
for WIRE_JSON compatibility, and one that checks only for WIRE
compatibility. The former check ignores protos in controller/servers,
since they do not need to adhere to this stricter definition.
This commit is contained in:
Johan Brandhorst-Satzkorn authored and GitHub committed 2022-06-17 11:58:37 -04:00
1 parent 6ffef1e4b5
commit 77bc45ae62
4 files changed
+48 -13

No files matched your search

+7 -1
View File
@@ -211,7 +211,13 @@ protobuild:
.PHONY: protolint
protolint:
@buf lint
@buf breaking --against 'https://github.com/hashicorp/boundary.git#branch=stable-website'
# First check all protos except controller/servers for WIRE_JSON compatibility
cd internal/proto && buf breaking --against 'https://github.com/hashicorp/boundary.git#branch=stable-website,subdir=internal/proto' \
--exclude-path=controller/servers \
--config buf.breaking.json.yaml
# Next check all protos for WIRE compatibility. WIRE is a subset of WIRE_JSON so we don't need to exclude any files.
cd internal/proto && buf breaking --against 'https://github.com/hashicorp/boundary.git#branch=stable-website,subdir=internal/proto' \
--config buf.breaking.wire.yaml
.PHONY: website
# must have nodejs and npm installed
+21
View File
@@ -0,0 +1,21 @@
# This file defines the breaking change configuration we use for
# files for which we require only JSON level compatibility checks,
# such as those used to describe the HTTP/JSON API we expose to the CLI,
# the Desktop client and the admin UI.
version: v1
name: buf.build/hashicorp/boundary
deps:
- buf.build/googleapis/googleapis
- buf.build/grpc-ecosystem/grpc-gateway
breaking:
use:
- WIRE_JSON
ignore_only:
FIELD_NO_DELETE_UNLESS_NUMBER_RESERVED:
# The proto files in controller/api are only exposed as json files so enforcing
# proto backward compatability doesn't make sense, except for maybe the names.
- controller/api
# Storage protos are used by gorm. Gorm relies on go tags and the json
# names to determine what columns to update so we don't care of the field
# numbers remain the same.
- controller/storage
+20
View File
@@ -0,0 +1,20 @@
# This file defines the breaking change configuration we use for
# files for which we require only WIRE level compatibility checks,
# such as those used to describe the gRPC API between worker and controller.
version: v1
name: buf.build/hashicorp/boundary
deps:
- buf.build/googleapis/googleapis
- buf.build/grpc-ecosystem/grpc-gateway
breaking:
use:
- WIRE
ignore_only:
FIELD_NO_DELETE_UNLESS_NUMBER_RESERVED:
# The proto files in controller/api are only exposed as json files so enforcing
# proto backward compatability doesn't make sense, except for maybe the names.
- controller/api
# Storage protos are used by gorm. Gorm relies on go tags and the json
# names to determine what columns to update so we don't care of the field
# numbers remain the same.
- controller/storage
-12
View File
@@ -3,18 +3,6 @@ name: buf.build/hashicorp/boundary
deps:
- buf.build/googleapis/googleapis
- buf.build/grpc-ecosystem/grpc-gateway
breaking:
use:
- WIRE_JSON
ignore_only:
FIELD_NO_DELETE_UNLESS_NUMBER_RESERVED:
# The proto files in controller/api are only exposed as json files so enforcing
# proto backward compatability doesn't make sense, except for maybe the names.
- controller/api
# Storage protos are used by gorm. Gorm relies on go tags and the json
# names to determine what columns to update so we don't care of the field
# numbers remain the same.
- controller/storage
lint:
use:
- DEFAULT