-
Notifications
You must be signed in to change notification settings - Fork 596
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
pandaproxy/sr: bazelize compatibility_protobuf test #24657
pandaproxy/sr: bazelize compatibility_protobuf test #24657
Conversation
215d783
to
e7a8052
Compare
e7a8052
to
e40d475
Compare
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 wonder if it's worth moving the well-known types from pandaproxy/BUILD
to schema_registry/protobuf
, as well?
Or maybe into /src/v/schema/protobuf
?
I tried to package up confluent_proto
, google_type_proto
, and well_known_proto
into their own cc_libraries, but failed to get that to work.
CI test resultstest results on build#60587
test results on build#60624
|
Don't depend on the protobuf library, then to get raw `.proto` files you have to know about how the `proto_library` rule works, instead just create a filegroup rule for the protos that the go test depends on, which is also consumed by the `proto_library` rule.
Implements: CORE-7549 -
compatibility_protobuf.cc
Had to change how the known types
.proto
files are ingested. Without the changes in theschema_registry_protos
bazel target, they were visible using the full local path from workspace. i.e.Backports Required
Release Notes