golangci / golangci-lint-action

Official GitHub Action for golangci-lint from its authors

Home Page:https://github.com/marketplace/actions/golangci-lint

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support comments instead of annotations

jirfag opened this issue · comments

Like golangci.com has worked.

How annotations look now:
image

They look similar to comments, but they don't appear in the comments list and on main page of a pull request.

commented

can it be made optional, default on

I see a lot of up-votes here,
can you please explain why current GitHub annotations aren't ok for you? do you miss only listing it in all comments list? or something else?

commented

In some cases when the pr is quite large then scrolling through to find the issue can take time. Also if I click the viewed button to collapse a file and then the annotation comes in then I will have to search for it.

In many cases running golangci-lint locally will be simpler but I find contributors are not running it locally even after the ci job fails, my teammates and I end up having to comment asking to fix linting issues. Before when golangci-lint was running as its own service we never had to comment to fix things.

I'm still thinking about implementation. I see the following options:

  1. A user of the action passes GitHub token. The action writes comments from the user's account. I think it's too confusing and we need a separate bot.
  2. A user creates a bot, specifies it's token. All comments are written from the bot. I think it's too difficult for users to configure.
  3. A user specifies configuration option like use_comments: true. Under the hood, we send requests to comment to our server, that uses a secret token of golangcibot and sends comments. We have no way to verify such comments and defend from spam. But it's easy to use.
  4. A user doesn't change the configuration. To make comments the user installs some GitHub app. This app subscribes to webhook "check run complete" and gets output from this action. After that it writes comments from it's bot. We can check signature on webhooks and defend from spam. But it's the extra step for users.
commented

not sure if one of the options encapsulates having the action comment.

something like https://github.com/marketplace/actions/comment-on-pr could be used internally (not copy-paste) and then the output of the linting is added to a markdown file that that gets commented in the pr?

note: this could already be done with two separate jobs.

thank you!
I thought that comments with

env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

are made from a user's login,
but it looks like that they are made from github-action bot. So, solution 1 can be ok.

I'm not sure when I will find time for that but if anyone wishes to help - here is how it can be implemented:

  1. check that current github-token (already used for fetching pull request diff) has access to make comments and it makes them from github-actions bot
  2. create new option disabled by default
  3. set golangci-lint output format json instead of github-actions
  4. parse json and make annotations from them if the option is disabled
  5. if the option is enabled - instead of annotations make comments
  6. before posting comments - fetch existing comments for pull like we did in golangci.com. Don't make more than 1 comment for a line.
  7. generate suggested fixes like we did in golangci.com
  8. if github fails to leave comments (it was a common case for golangci.com): rate limiting, blocked, 500 in API, etc - fall back to making annotations.

Also, I don't have experience in tests for js, so the current action doesn't have any tests =( It will be very cool if someone can introduce tests (jest?) with this change, because logic here is complex.

just a drive-by comment, but, wrt tests, it seems there is the beginning of a Go-based SDK for github actions:

it looks interesting, thank you

Just came across this and at least from a permissions standpoint comments, especially for forked PRs, could be resolved via pull_request_target event.

commented

whats the status of this issue? I find having it in comments is really helpful than in annotations

Wow ! This is an insane default. WTF ... Please, support this !

When changing the format to json, it breaks ... Worse user experience there ...

Error: Failed to run: Error: please, don't change out-format for golangci-lint: it can be broken in a future, Error: please, don't change out-format for golangci-lint: it can be broken in a future

If you want to do something great, write the lines + annotations. Why do only 1 ?

Very useful feature to have!

Annotations are nice, but I have to go hunt them down.

Every other aspect of my CI, if its a blocking issue to the pull request, it gets a sticky comment -> https://github.com/marocchino/sticky-pull-request-comment

Once said issue is resolved, comment cleans itself up.

When I make a round on my outstanding PRs, it'd be nice not to have to click to a handful of views to get the answers I need.

Comments ftw.

commented

Yes, I need him very much!So what's the progress now?

👀 also curious about update on this. I would much rather prefer a comment versus annotation. usually I just click a link to the main pull request page from slack. it is more often the code reviewer that is actually viewing the 'files changed' tab.