Hi, another question for you.

Is it possible to have buf follow symlinks? The way the build folder is setup with bazel (by default) means the original repo is symlinked. We need to use the build folder as bazel pulls in all the external proto files we need to compile with.

Thanks, Adam

I am dealing with a set of proto files from a couple legacy repos that I cannot change. I can successfully build an image from these protos, but I cannot generate stubs from them with protoc. To generate stubs correctly I would have to write some nasty commands to automatically fixup the proto files before building the image. However, if I could build a JSON image, modify that really easily with jq, and then convert that to a binary image with buf to use as input to protoc, I wouldn't have to resort to hack-ily sed-ing the proto files. Is this possible?

P.S. Converting binary images to JSON would also be useful for introspection, but that is not necessary for me right now.

Documentation says

Note that buf does not allow comment-driven ignores.

While I understand the reasoning, I still suggest reconsidering. For example I just finished integrating buf checks in a code base which is a large monorepo. Most protos conform to almost all checks, but for most checks there's a few proto files that don't. Of course I could fix everything (actually sometimes that's impossible, but okay), but that would involve a ton of work. The yaml solution is far from perfect as every time the config changes the whole repository needs to be re-linted rather than just one proto file that has changed. Not to mention a huge config with all the checks and files needs to be created and maintained. I would prefer to silence those places and create issues for maintainers to fix whatever is possible at their own pace. Instead I have to only enable a couple of very basic checks for the whole repo. Which means most of new bad code will not be rejected, so while existing issues are being fixed new ones will pop up.

As you can see, while principled, the no-comments approach is far from practical as it makes it impossible to implement buf check in a large repository in a meaningful way.

No matter what I do, buf check lint checks all directories. I can't get it to actually ignore lint errors from a particular directory.

Is there a way to make this work?

Thank you!

mkdir foo
cd foo
go mod init foo.bar
go get google.golang.org/protobuf/proto
go get github.com/bufbuild/buf/cmd/buf

The binary installed will drop any custom options defined in your proto files when generating the Image file.

Is this expected? If so, what is the recommended way to delete a service?

Config:

build:
    roots:
        - proto/
lint:
    use:
        - DEFAULT
        - FILE_LOWER_SNAKE_CASE
breaking:
    use:
        - FILE
    ignore:
        - company/proto/iam/v1test

Steps:

• Delete: company/proto/iam/v1test.
• Run: buf check breaking --against-input .git#branch=master

Result:

:1:1:Previously present file "company/proto/iam/v1test/service.proto" was deleted.

Expected:

Breaking change detector to pass.

For easy implementation/integration with pre-commit, could a .pre-commit-hooks.yaml be added to the repository?

For a local repository containing some *.proto files, we should be able to add something like the following pre-commit hook to the .pre-commit-config.yaml:

- repo: https://github.com/bufbuild/buf
    rev: v0.41.0
    hooks:
      - id: buf
        name: buf linter
        description: Validates proto files
        entry: buf
        language: golang
        language_version: 1.15.8
        pass_filenames: false
        args: [lint --path ./api]

Hi there,

zsh completion is not working, I'm getting _arguments:comparguments:325: invalid option definition: --log-format[The log format [text,color,json].]:

Generated completion looks like:

function _buf {
  local -a commands

  _arguments -C \
    '--log-format[The log format [text,color,json].]:' \
    '--log-level[The log level [debug,info,warn,error].]:' \
    '--timeout[The duration until timing out.]:' \
    "1: :->cmnds" \
    "*::arg:->args"

It seems cobra doesn't escape flag description properly: https://github.com/spf13/cobra/blob/v1.0.0/zsh_completions.go#L334 and braces from flag descriptions with permitted values break it.

I'm not sure whether it's done on purpose for some flexibility or not.

% zsh --version
zsh 5.8 (x86_64-pc-linux-gnu)

Before:

message Bar {
  enum Foo {
    FOO_UNSPECIFIED = 0;
    FOO_A = 1;
  }
  Foo field = 1;
}

After:

enum Foo {
  FOO_UNSPECIFIED = 0;
  FOO_A = 1;
}

message Bar {
  Foo field = 1;
}

This is currently detected as a breaking change with a message like:

Field "1" on message "Bar" changed type from "Bar.Foo" to "Foo".

This is not actually a breaking change in the wire format as the enum values are the same even if the type has changed name.

The buf check breaking command has support for branches and tags when checking against a git repository input. I want it to accept an arbitrary git reference, like refs/remotes/origin/master or refs/pull/3/head.

In my humble opinion, if you're not afraid of breaking backwards compatibility, it makes sense to remove branch and tag flags, since they're just a strict subset of providing the reference directly (and removing them would simplify some of the flag logic).

Hello, it would be great if you could provide also Windows binaries.

I'm requesting this because we currently use protoc (via protobuf-gradle-plugin) so it would be wonderful to use protoc-gen-buf-check-lint protoc plugin for linting.

If I could help with this, just let me know.

Bumps github.com/rs/cors from 1.8.2 to 1.8.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This changes the definition of buf curl --reflect-protocol slightly to make it such that this flag no longer has an auto value. Instead, this flag is defined as "use a specific reflection protocol. if no protocol is set, we will choose". This means there is no special value needed to be understood by our users - the default value for --reflect-protocol is no value.

As part of this change, this changes the ReflectProtocol type to be an enum in line with the rest of the codebase and our code standards (although we should make it more clear in our code standards, its a little obscure to be fair). We prefer int enums over strings because they do not allow people to do things such as cast user-provided flag values to their type directly :-) enums should be just that, and parsing should be commonly validated in the package that provides them. bufanalysis is a good example of this style (that bufcurl is now largely updated to reflect).

I was working through examples for buf curl, and noticed that it pretty-prints the output JSON. Whether we should do this or not is worthy of a quick conversation, but the buf tool's overall stance (including for --error-format=json) has been to print compact JSON, and leave it to the user to format their JSON with other tools if they want, sticking with the unix philosophy of doing one thing well, i.e. we give the user the most compact output possible, and they can use jq to format if they want:

$ buf curl https://demo.connect.build/buf.connect.demo.eliza.v1.ElizaService/Say -d '{"sentence":"Hello."}'
{"sentence":"Hello...I'm glad you could drop by today."}

$ buf curl https://demo.connect.build/buf.connect.demo.eliza.v1.ElizaService/Say -d '{"sentence":"Hello."}' | jq
{
  "sentence": "Hello, how are you feeling today?"
}

In going through the code to put up the proposal to make this change, I noticed that bufcurl is using proto.Umarshal/Marshal and protojson directly, which we want to avoid - we've strived to use protoencoding everywhere so we have the same behavior for Protobuf encoding everywhere, and can easily change it later. Example here being we always want to use deterministic wire marshaling, and we want to call json.Compact on the result for JSON marshaling due to the protojson purposefully non-determinstic JSON marshalling issue (and if this were to ever be fixed, we could easily change the usage of json.Compact in one place). This updates the code to use protoencoding everywhere in bufcurl, and I'll have a follow-up to do this in bufstudioagent (the only other place in bufbuild/buf that doesn't use protoencoding) as well.

Let me know your thoughts especially re: pretty-printing, we should come to agreement on that 100%.

When specifying directories in buf.work.yaml, buf lint will no longer report COMMENT errors.

Setup

# buf.yaml

version: v1

lint:
  use:
    - DEFAULT
    - COMMENTS
    - PACKAGE_NO_IMPORT_CYCLE

// service.proto

syntax = "proto3";

package test.activity.v1alpha;

service Service {
  rpc Test(test.activity.v1alpha.TestRequest) returns (test.activity.v1alpha.TestResponse);
}

message TestRequest {
  string value = 1;
}

message TestResponse {
  string value = 1;
}

Working example

When you only have buf.yaml in the top level, linting works as intended:

$ tree
.
├── buf.yaml
└── test
    └── activity
        └── v1alpha
            └── service.proto

$ buf lint
test/activity/v1alpha/service.proto:7:1:Service "Service" should have a non-empty comment for documentation.
test/activity/v1alpha/service.proto:8:3:RPC "Test" should have a non-empty comment for documentation.
test/activity/v1alpha/service.proto:11:1:Message "TestRequest" should have a non-empty comment for documentation.
test/activity/v1alpha/service.proto:12:3:Field "value" should have a non-empty comment for documentation.
test/activity/v1alpha/service.proto:15:1:Message "TestResponse" should have a non-empty comment for documentation.
test/activity/v1alpha/service.proto:16:3:Field "value" should have a non-empty comment for documentation.

Issue example

When you put the protobuf files in the proto directory and add a buf.work.yaml file, buf lint will no longer output any errors.

# buf.work.yaml

version: v1

directories:
  - protos

$ tree
.
├── buf.work.yaml
├── buf.yaml
└── protos
    └── test
        └── activity
            └── v1alpha
                └── service.proto

$ buf lint
# empty response

The interesting thing is, it seems to only be the COMMENT lint rules. If I rename the service to Test, I get this error when linting:

$ buf lint
protos/test/activity/v1alpha/service.proto:7:9:Service name "Test" should be suffixed with "Service".

Bumps github.com/docker/docker from 20.10.21+incompatible to 20.10.22+incompatible.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.