bufbuild / buf-lint-action Goto Github PK

It's idiomatic to create major version tags so users can use them in their actions reducing code churn to get the latest compatible version e.g.
bufbuild/buf-lint-action@v1

Could you add the creation of:

• v<major>

You can see this in practice actions/checkout.

example run: https://github.com/harmony-development/protocol/runs/4670337736?check_suite_focus=true

with a configuration like:

  lint-protos-staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: bufbuild/[email protected]
      - uses: bufbuild/buf-lint-action@v1
        with:
          input: 'staging'

and a file structure like

 .
├──  CMakeLists.txt
├──  FAQ.md
├──  GUIDELINES.md
├──  LICENSE
├──  README.md
├──  shell.nix
├──  stable
│  ├──  auth
│  │  └──  v1
│  │     └──  auth.proto
│  ├──  batch
│  │  └──  v1
│  │     └──  batch.proto
│  ├──  buf.yaml -> ../.buf.yaml
│  ├──  chat
│  │  └──  v1
│  │     ├──  channels.proto
│  │     ├──  chat.proto
│  │     ├──  guilds.proto
│  │     ├──  messages.proto
│  │     ├──  Permissions.md
│  │     ├──  permissions.proto
│  │     └──  stream.proto
│  ├──  CMakeLists.txt
│  ├──  emote
│  │  └──  v1
│  │     ├──  emote.proto
│  │     ├──  stream.proto
│  │     └──  types.proto
│  ├──  harmonytypes
│  │  └──  v1
│  │     └──  types.proto
│  ├──  mediaproxy
│  │  └──  v1
│  │     └──  mediaproxy.proto
│  ├──  name-resolution
│  │  ├──  example
│  │  │  ├──  go.mod
│  │  │  └──  main.go
│  │  └──  name-resolution.md
│  ├──  profile
│  │  └──  v1
│  │     ├──  appdata.proto
│  │     ├──  profile.proto
│  │     ├──  stream.proto
│  │     └──  types.proto
│  ├──  rest
│  │  └──  rest.md
│  └──  sync
│     └──  v1
│        └──  sync.proto
└──  staging
   ├──  buf.yaml -> ../.buf.yaml
   ├──  CMakeLists.txt
   └──  voice
      └──  v1
         └──  voice.proto

buf attempts to lint a file from stable, but fails because it's not in the staging directory

I have a reproducing repo at https://github.com/carols10cents/buf-repro, specifically in carols10cents/buf-repro#3.

This applies to the buf-breaking-action too, but I arbitrarily picked this repo to file the issue in. Let me know if you'd like one over there too.

The .github/workflows/buf-lint.yml contains this (which also runs buf breaking):

name: "Protobuf Lint"
on:
   pull_request:
     types:
       - labeled
       - opened
       - reopened
       - synchronize
jobs:
  lint-protos:
    runs-on: ubuntu-latest
    name: Buf lint
    steps:
      # Run `git checkout`
      - uses: actions/checkout@v4
        if: ${{ !contains(github.event.pull_request.labels.*.name, 'incompatible protobuf') }}
        with:
          fetch-depth: '100'
          submodules: true
      # Install the `buf` CLI
      - uses: bufbuild/buf-setup-action@v1
        if: ${{ !contains(github.event.pull_request.labels.*.name, 'incompatible protobuf') }}
      # Run breaking change detection against the `main` branch
      - uses: bufbuild/buf-breaking-action@v1
        if: ${{ !contains(github.event.pull_request.labels.*.name, 'incompatible protobuf') }}
        with:
          against: 'https://github.com/influxdata/influxdb_iox.git#branch=main'
      # Lint your Protobuf sources
      - uses: bufbuild/buf-lint-action@v1
        if: ${{ !contains(github.event.pull_request.labels.*.name, 'incompatible protobuf') }}

      # Be helpful if the lint fails
      - name: Lint failure! Read this :)
        if: ${{ failure() }}
        run: |
          echo "If you want to make changes forbidden by this lint, please"
          echo "coordinate with the IOx team, add the 'incompatible protobuf' label"
          echo "to the PR, and rerun this test"

The PR reverts a commit that fixed a previous issue with file imports; that is, it breaks again and I expected the action run to fail-- but it passed.

However, toggling open the logs for buf-breaking-action shows:

Run bufbuild/buf-breaking-action@v1
Failure: bulk_ingester/protos/influxdata/iox/bulk_ingester/v1/progress.proto: import "generated_types/protos/influxdata/iox/column_type/v1/type.proto": file does not exist
Failure: bulk_ingester/protos/influxdata/iox/bulk_ingester/v1/progress.proto: import "generated_types/protos/influxdata/iox/column_type/v1/type.proto": file does not exist
No breaking errors were found.

and toggling open the logs for buf-lint-action shows:

Run bufbuild/buf-lint-action@v1
Failure: bulk_ingester/protos/influxdata/iox/bulk_ingester/v1/progress.proto: import "generated_types/protos/influxdata/iox/column_type/v1/type.proto": file does not exist
Failure: bulk_ingester/protos/influxdata/iox/bulk_ingester/v1/progress.proto: import "generated_types/protos/influxdata/iox/column_type/v1/type.proto": file does not exist
No lint errors were found.

I expected these Failure messages to cause the job to fail, because the actions aren't able to actually check these files.

Just tried setting this up on a private repo and I see the output in the Github Actions logs, but it's not posting anything to the PR.

My config:

  buf:
    name: Buf
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - uses: bufbuild/[email protected]
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}

      - uses: bufbuild/buf-lint-action@v1
        continue-on-error: true
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}

I might be doing something dumb but I didn't see anything obvious in the documentation (also looked at the source code of this action and still not sure what I'm doing wrong).

Thanks!!

Problem

When the buf.yaml specifies module dependencies, the buf-lint action fails.

For example, suppose you have the following buf.yaml:

name: buf.build/acme/weather
deps:
  - buf.build/beta/googleapis

When buf lint is run in the action, the console will reveal something along the lines of:

Error: buf: downloading buf.build/beta/googleapis:aced890b7e944f9ca174481ad810ca5f

In this case, buf-lint treats anything written to stderr as a failure, so the action as a whole is failed.

Solution

There's a few different strategies we can use to fix this.

1. Adding an option to silence the buf: downloading ... messages.
2. Distinguish command errors from lint errors with a different exit code (they currently both return exit code 1).
3. Resolve dependencies with buf beta mod update before running buf lint.

This action seems vulnerable to command injection due to the use of child.execSync on unsanitized user input. See here for documentation which says

"Never pass unsanitized user input to this function. Any input containing shell metacharacters may be used to trigger arbitrary command execution."

Is there any plans to change this? Or is it by design to execute user input inside a shell in this way?

This also affects other bufbuild/buf-* actions

When trying to use the buf-lint-action on this repo: https://github.com/andrewtsun25/djin-proto/tree/buf-github-actions, the build consistently fails on buf-lint-action complaining that "branch is not main". It seems like buf-setup-action has completed but this action cares what the branch name is? I've looked through the source code, and there doesn't seem to be a statement that produces this message in any of the src files. I've also read this wiki as well and followed it, except changed all references of "main" to "master": https://docs.buf.build/ci-cd/github-actions.

Am I missing a step or some undocumented parameter? Or is there a bug in this action?

Hello buf team!

Found an interesting issue while setting up a repo with the lint action and when using the latest buf version 1.0.0-rc12 where basically if the buf.lock file is committed and present, the lint fails with Failure: branch is not main. If the buf.lock file is not present, then linting proceeds as expected but this is of course not ideal since the lock file should be commited & pushed. The lock file was not manually modified and was generated by buf mod update.

Perhaps this is related to the removal of the branch field from buf.lock on 1.0.0-rc12?

Could you assist please? Thank you!

It would be good to capture the output from errors in a variable so it can be used to annotate PR's or workflow runs.

The bufbuild/buf-lint-action@v1 action currently causes the job that calls it to fail if there are any lint problems. Since these lint problems may not be mandatory fixes (especially if they're preexisting problems), it would be nice if the action had an input that causes it not to fail.

It is treated as a failure because the linter is very reasonably returning a nonzero exit code, which GitHub interprets as a failure, so this status would need to be caught. There is also the question of whether the ::warning signal should be used instead of ::error in this case, but that doesn't appear to govern any GitHub workflow functionality.

We are using this action and get a deprecation warning of node 16. If I'm right the only step missing is the release as main already is updated to node 20. Could you please consider creating a new release, Thanks.

Hello,

I added this action to a private repo and it runs and then fails with a few errors that I've since fixed locally. The linter is stuck on two issues:

1. The action is not properly using the enum_zero_value_suffix that I overrode in buf.yaml
   The buf.yaml is in the project root, and looks like

version: v1
deps:
  - buf.build/googleapis/googleapis
  - buf.build/grpc-ecosystem/protoc-gen-swagger
breaking:
  use:
    - FILE
lint:
  use:
    - DEFAULT
  enum_zero_value_suffix: _NONE

I see error annotations for each enum in the proto, such as Enum zero value name "ERROR_CODE_NONE" should be suffixed with "_UNSPECIFIED".

2. My foo.proto package is named like foo.v1 and I have the directory structure as <root>/foo/v1/foo.proto
   So I specify in the github action yaml like so:

      - name: Lint Protos
        uses: bufbuild/buf-lint-action@v1
        with:
          input: 'foo'

But the linter still errors, claiming that the package isn't in a foo/v1 directory when it actually is:
Files with package "foo.v1" must be within a directory "foo/v1" relative to root but were in directory "v1".

One more detail: I was missing a version in the package name initially, but I have since changed the package name to include it. Not sure if that matters or not.

Hi, I'm trying to use buf lint in an existing protobuf code base. There are files that does not pass the buf lint rules, in this case buf-lint-action itself fails because those files are not present in the pull request diff:

Failed to write comments in-line: Unprocessable Entity: "Path is invalid and Pull request review thread review comments is invalid"

I think our use case is common for teams that has some protobuf files before introducing buf as their linter tool. Please consider supporting this use case.

As an alternative solution, this is what I chose to do:

1. Run buf lint --error=format=json
2. Use jq to format output in this format so that GitHub Pull Request can show them under "Unchanged files with check annotations" section (in "Files changed" tab).

Also because the source code does not provide a FOSS license, I am not allowed to fix your program.

Thanks!