Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support comments instead of annotations #5

Open
jirfag opened this issue May 4, 2020 · 16 comments
Open

Support comments instead of annotations #5

jirfag opened this issue May 4, 2020 · 16 comments
Labels
enhancement New feature or request

Comments

@jirfag
Copy link
Member

jirfag commented May 4, 2020

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.

@tac0turtle
Copy link

can it be made optional, default on

@jirfag
Copy link
Member Author

jirfag commented May 13, 2020

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?

@tac0turtle
Copy link

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.

@jirfag
Copy link
Member Author

jirfag commented May 18, 2020

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.

@tac0turtle
Copy link

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.

@jirfag
Copy link
Member Author

jirfag commented May 18, 2020

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.

@jirfag
Copy link
Member Author

jirfag commented May 22, 2020

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.

@sbinet
Copy link

sbinet commented May 22, 2020

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

@jirfag
Copy link
Member Author

jirfag commented May 22, 2020

it looks interesting, thank you

@embano1
Copy link

embano1 commented Nov 24, 2020

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

@ohmpatel1997
Copy link

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

@tchaton

This comment was marked as outdated.

@kamushadenes
Copy link

Very useful feature to have!

@joshua-temple
Copy link

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.

@McDonald755
Copy link

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

@kelleyDanger
Copy link

👀 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests