Support Checks API

[pqn]

It would be cool if instead of regular comments, the fixes could be suggested as part of the Checks API.

There's a more informative picture here: https://docs.github.com/en/developers/apps/guides/creating-ci-tests-with-the-checks-api#step-25-updating-the-check-run-with-ci-test-results

[platisd]

Interesting, I haven't used them before. I guess you mean that the different issues shouldn't be posted as comments but instead for a "fix this" option to be displayed at the end of the run?

Two questions. If a user clicks in the "fix" button:

1. What should happen if there's an error but no suggestion on how to fix? Just leave a comment?
2. What happens in the case of false positive warnings that the user may want to suppress? Will clicking "fix" blanket-apply everything? Then a user may have to manually revert the unwanted ones.

[pqn]

Interesting, I haven't used them before. I guess you mean that the different issues shouldn't be posted as comments but instead for a "fix this" option to be displayed at the end of the run?

The issues show up as an annotation as opposed to a comment (but both are rendered inline in the code). So I think the main benefit is for a code review with a lot of (automated) annotations and (manual) reviewer comments, you can hide one category and keep the other visible. And then as you mentioned, there is a single fix button instead of manually having to accept many suggestions.

I did some Googling and found a couple repos which are examples of triggering annotations from GH Actions, although I haven't tested them:

• https://github.com/yuzutech/annotations-action
• https://github.com/Attest/annotations-action

1. What should happen if there's an error but no suggestion on how to fix? Just leave a comment?

Yes, you should be able to have an annotation.

2. What happens in the case of false positive warnings that the user may want to suppress? Will clicking "fix" blanket-apply everything? Then a user may have to manually revert the unwanted ones.

This is a good point. I assume users have tuned their configuration to have minimal false positives. Then I think the workflow would be to ask them to add // NOLINT, etc. to the places with false positives, push the changes and re-trigger clang-tidy, and then be left with only fixes they want.