clippy-action
clippy-action copied to clipboard
giraffate
clippy warnings are escalated to errors
i'm working on a repo that has a number of clippy warnings. I would like these to be reported, but not fail the job (clippy errors should fail the job, but not warnings)
how to i stop this action from escalating warnings into hard errors?
see https://github.com/mavlink/rust-mavlink/actions/runs/3575705031/jobs/6012579389
Thanks for creating an issue!
It looks like that the GitHub token doesn't have write permissions. Could the token has write permissions be used? https://github.com/mavlink/rust-mavlink/actions/runs/3575705031/jobs/6012579389#step:5:101
If it's a forked repository, it could be the following case. In that case, it would be better to use reporter: 'github-pr-review'.
https://github.com/reviewdog/reviewdog#graceful-degradation-for-pull-requests-from-forked-repositories
it is a forked repo. It's an open-source repo, so in the general case PRs will often be from forked repos. I'm a little unclear on the difference between these reporters.
I'll try changing the reporter and see what difference that makes to the behaviour
here is the PR, by the way - https://github.com/mavlink/rust-mavlink/pull/143
github-pr-review gives GitHub PullRequest review comments like below:
https://github.com/reviewdog/reviewdog#reporter-github-pullrequest-review-comment--reportergithub-pr-review
I'm a little unclear on the difference between these reporters.
And sorry for poor documentation, I believe I need to write more docs.
here is the output from the new job with the updated reporter - https://github.com/mavlink/rust-mavlink/actions/runs/3581397435/jobs/6024409026
It appears that warnings are still escalated to errors (the 'check' output on the diff uses red markings, as opposed to the yellow warnings), however the job itself has not returned an error code (so is reporting a green tick). That's probably good enough, even if not perfect.
I'm now running the job again, but with clippy errors (as opposed to warnings) to check the behaviour in that case. Now I would expect the job to fail
output is here - https://github.com/mavlink/rust-mavlink/actions/runs/3581634546/jobs/6024921436
update: the job has not failed, so I still don't have the behaviour i'm after.
| behaviour | repo contains... | clippy-action reports... | action status |
|---|---|---|---|
| github-pr-check | clippy warnings | errors | failed |
| github-pr-review | clippy warnings | errors | passed |
| desired | clippy warnings | warnings | passed |
| github-pr-check | clippy errors | errors | failed |
| github-pr-review | clippy errors | errors | passed |
| desired | clippy errors | errors | failed |
does the above make sense?
neither github-pr-check nor github-pr-review give me the behaviour I want, namely that clippy warnings do not fail the build, and that clippy errors do.
Is this due to a reviewdog or clippy-action limitation? Or is this a limitation in the API exposed by github when you don't have an access token?
It appears that warnings are still escalated to errors (the 'check' output on the diff uses red markings, as opposed to the yellow warnings), however the job itself has not returned an error code (so is reporting a green tick). That's probably good enough, even if not perfect.
I'm fixing error/warning reporting bugs in https://github.com/giraffate/clippy-action/pull/25 but I haven't try it in a forked repo.
GitHub status depends on level option. info and warning give Neutral, and error (default) gives Failed.
https://github.com/reviewdog/reviewdog#reporter-github-checks--reportergithub-pr-check
relevant upstream issues-
- https://github.com/reviewdog/reviewdog/pull/1170
- https://github.com/reviewdog/reviewdog/issues/856
One of the upstream issues has been resolved. Does that unblock this ticket?
One of the upstream issues has been resolved. Does that unblock this ticket?
ping @giraffate