Closed dnr closed 6 days ago
I am unable to reproduce the error state. I built an example that fails FILE
level checks but passes WIRE
level checks, built images with protoc -o
, and did not get any check failures with:
buf breaking image1.bin --against image2.bin --config buf.yaml
Could you please provide a repro of the problems you're running into?
Closing issue until reproduction is provided - we ask for repros as our team gets a lot of issues, and needs to be able to efficiently investigate them. If you can provide a reproduction, we will be happy to re-open!
Fair enough, and thanks for trying!
I reduced my case to a minimal repro using buf 1.32.2 and just a v1 vs v2 config file, with binary images with a single renamed field:
https://github.com/dnr/buf-repro
$ ./run.sh
Buf version:
1.32.2
Correctly uses 'WIRE' rules (no output):
Uses rules besides 'WIRE':
temporal/server/api/clock/v1/message.proto:1:1:Field "1" with name "wll_clock" on message "HybridLogicalClock" changed option "json_name" from "wallClock" to "wllClock".
temporal/server/api/clock/v1/message.proto:1:1:Field "1" on message "HybridLogicalClock" changed name from "wall_clock" to "wll_clock".
(edit: oops, repo was marked private initially, changed to public now)
@doriable could you take another look, or let me know if I missed something obvious with the repro?
This issue was resolved in the PR :) It will go out with the next release!
What's up?
Sorry for lack of test case, but this should be pretty easy to reproduce:
I was trying to set up a check using
buf breaking
like this:The image files were not generated by buf, they were generated by
protoc -o
I tried using buf 1.32.2 with a config like:
This did the breaking check using the default
FILE
level, theWIRE
level was not respected. I also tried addingignore
settings that were not respected.I downgraded to buf 1.6.0 and used the same command line with the same config except
version: v1
, and it respected the breaking settings as expected.