Our current clang-tidy setup is held together with duct tape and string. I've had to fork the repo and tweak the action and script considerably to get it to behave somewhat decently, and even then they had no real solution for the permission scoping issues preventing us from using the more useful features (reviews/comments).
ZedThree/clang-tidy-review however does; it uses a split workflow to explicitly handle it (though I need to test it, as there's an issue reporting that it doesn't work for them). The initial pull_request event (which is demoted to read-only permissions) simply uploads the results to the actions cache, and then the subsequent workflow_run -> completed event (which should still run with write permissions) fetches them (from the 'master' branch, so that workflow itself will be "old") and then handles the features requiring write permissions (reviews/comments).
This in theory sorts that problem.
However, it doesn't appear to distinguish between errors and warnings, so it'll likely have to be tweaked as well.
Ideally warnings (that are left as warnings) shouldn't cause build failures. Warnings promoted to errors (and errors themselves) should.
But as-is, it seems like it only exposes num_comments (which would be a total of all comments, warning or error, unfortunately) which you'd check and fail a build on.
Our current clang-tidy setup is held together with duct tape and string. I've had to fork the repo and tweak the action and script considerably to get it to behave somewhat decently, and even then they had no real solution for the permission scoping issues preventing us from using the more useful features (reviews/comments).
ZedThree/clang-tidy-review however does; it uses a split workflow to explicitly handle it (though I need to test it, as there's an issue reporting that it doesn't work for them). The initial
pull_requestevent (which is demoted to read-only permissions) simply uploads the results to the actions cache, and then the subsequentworkflow_run->completedevent (which should still run with write permissions) fetches them (from the 'master' branch, so that workflow itself will be "old") and then handles the features requiring write permissions (reviews/comments).This in theory sorts that problem.
However, it doesn't appear to distinguish between errors and warnings, so it'll likely have to be tweaked as well.
Ideally warnings (that are left as warnings) shouldn't cause build failures. Warnings promoted to errors (and errors themselves) should.
But as-is, it seems like it only exposes
num_comments(which would be a total of all comments, warning or error, unfortunately) which you'd check and fail a build on.