Super-linter: Support the GitHub Checks Run UI

[GaboFDC]

Is your feature request related to a problem? Please describe.
After the super-linters runs, you have to go to the workflow logs, and then the step, and look at the logs, to see the errors that were found. This is not ideal and error-prone.

Describe the solution you'd like
A better approach would be to use the Checks Run UI to report the errors directly into the PR/code lines, to better visibility.

Describe alternatives you've considered
Other linters already do this like https://github.com/andrewmcodes/rubocop-linter-action and https://github.com/devmasx/brakeman-linter-action

Additional context
I think this is a really big feature, but it will also improve a lot the super-linter, and we could leverage how others already do it.

[Hanse00]

Sounds like this could be related to #7.

[GaboFDC]

How I see it #7 is more about allowing the super-linter to be run as many specific linters on their own.
Independent of that, the current way that the super-linter reposts the errors in only on the logs, this is about changing that to also report via the API more nicely, so I think is still a separate issue

[Hanse00]

Fair enough :)

I think there's a natural progression here:

• Start by doing what you're suggesting, put the result into a "Check" that uses the particular UI
• Then it'll be easier to break the one check into multiple checks

[hazcod]

And more interestingly, be able to comment on pull requests like reviewdog does.

[peternewman]

And more interestingly, be able to comment on pull requests like reviewdog does.

:100: This is also potentially as simple as just loading and unloading the relevant problem matcher:
https://github.com/actions/toolkit/blob/master/docs/problem-matchers.md

With the advantage problem matchers do them as annotations rather than noisy and stale comments (when you fix them).

[SeanTAllen]

There's a small problem with annotations and the default settings for super-linter. By default, super-linter is validating the entire codebase. However, annotations attempt to link the last commit so if there is a linting error that comes from something that wasn't in the most recent commit, clicking through from the UI will take you... nothing.

There is still a nice error message on the checks page but the click through from it will result in a subpar experience. This isn't a reason to not support the check run ui, it might however be a reason to raise this issue with the folks who maintain the check run ui to better support a use case like super-linter's validate entire codebase (which I think is the correct default).

[peternewman]

There's a small problem with annotations and the default settings for super-linter. By default, super-linter is validating the entire codebase. However, annotations attempt to link the last commit so if there is a linting error that comes from something that wasn't in the most recent commit, clicking through from the UI will take you... nothing.

I was going to say the thing here is to wait for GitHub to get it sorted, as they display fine on the commit, but actually looking just now it seems they have sorted it, it shows up nicely on the PR files view too:
https://github.com/codespell-project/actions-codespell/pull/16/files

Well sort of, it's somewhat inconsistent, see these two views of the same commit:
https://github.com/codespell-project/actions-codespell/commit/f23150ba0a1f8565249f73135c5be52855efbcae
https://github.com/codespell-project/actions-codespell/pull/16/commits/f23150ba0a1f8565249f73135c5be52855efbcae

There is still a nice error message on the checks page but the click through from it will result in a subpar experience. This isn't a reason to not support the check run ui, it might however be a reason to raise this issue with the folks who maintain the check run ui to better support a use case like super-linter's validate entire codebase (which I think is the correct default).

Yeah they do seem to be progressing some bits of this, I'd say it's pretty close given the PR commit view shows it already.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[GaboFDC]

This would still be a nice to have, but need some work on it

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[hazcod]

Reopen

[jlongman]

As a note, I have a fork of super-linter that would super-lint in Bitbucket (and limited support for CodeBuild). (Note I've not pushed to github in a long time, so I won't bother linking it, the latest rebase was v3.6.0. I'm seriously considering abandoning it as the shell-based nature of the project is too hard to use patterns that what would be simple in a higher-level language and recovering from constant refactors is too much work. Additionally the kitchen sink size of the container image is more painful outside of github.)

However, the approach I took was to create output parsers (in python) which were customized by parser type and fall back to a default format (shellcheck iirc) when there wasn't a custom parser. It was trivial to use python features to find a name-matching parser and fall back if not found. The parsers then output a data object which was contains line information for example, or if not a default call with sparse details, and send to the BB REST API.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[Yimsiyouna]

[email protected] from my Galaxy
-------- Original message --------From: "github-actions[bot]" [e-mail] Date: 1/13/21 07:55 (GMT+07:00) To: github/super-linter [e-mail] Cc: Subscribed [e-mail] Subject: Re: [github/super-linter] Support the GitHub Checks Run UI (#151)

This issue has been automatically marked as stale because it has not had recent activity.

It will be closed in 14 days if no further activity occurs.

Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[hazcod]

Unstale.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[hazcod]

Unstale