Conversation
| $(BIN)/buf generate buf.build/bufbuild/protovalidate:$(PROTOVALIDATE_VERSION) | ||
| $(BIN)/buf generate buf.build/bufbuild/protovalidate-testing:$(PROTOVALIDATE_VERSION) | ||
| $(BIN)/buf generate |
There was a problem hiding this comment.
I agree that it's helpful to have local proto files for debugging. But PROTOVALIDATE_VERSION and buf.lock competing over the exact version seems like a footgun.
Maybe the least controversial thing to do is to cut a protovalidate release that contains the new test protos?
There was a problem hiding this comment.
I’m not following. pv-go is doing this exact thing with no issues. I would really prefer for this to follow that pattern. Being able to change protos while debugging issues is much quicker than constantly having to cut protovalidate releases.
There was a problem hiding this comment.
It's good that we haven't had an issue with it so far. I didn't realize the Go implementation already does it. LGTM, and hopefully find a better solution down the road.
2 participants
The unit tests in this repo use Protobuf definitions from the conformance suite, which works but it makes debugging issues a bit difficult. It is extremely helpful to have local protos in the repo that can be changed for tests to debug issues.
This follows the example in protovalidate-go by creating a
validations.protoand copies the definitions currently being used from conformance into this proto.