Closed itaischwartz closed 1 year ago
I can see the desire for this on face value, but on balance, I think we should not implement this. In the 99% case, you want to make sure that your inputs are properly configured, and having a source with no .proto
files is a clear sign that something is incorrect. I assume you'd likely want to set up the entire workflow for Protobuf in your repository at the same time you add your first .proto
files - this makes sense, and without this flag you can't complete that. However, if you then use this flag after you have 1+ .proto
files committed, you're then risking that the buf breaking
command is incorrectly returning no errors in the future, as running buf breaking
against 0 .proto
files will always result in no breaking changes, and the most likely case where you have 0 .proto
files is a misconfiguration.
The mitigation here when setting up your repository for Protobuf is to just comment out any invocations of buf breaking
as part of your CI pipeline, then uncommenting them once there are .proto
files.
Closing for now, but if we ever revisit this, we'll update this issue.
Another note: I assume this issue is related to https://github.com/bufbuild/buf/issues/2070. The mitigation here is to implement the if 0 .proto files -> do not run buf breaking
as part of your GitHub Action.
Currently, when running
buf breaking --against .git#branch=main
against a branch w/o proto files results in the following errorFailure: no .proto target files found
This means that for new repositories, I can add
buf breaking
to the CI only after we merged at least 1 proto file. I would like to have the option to emit this error (something likebuf breaking --allow-empty-source --against <source>
)