[X] Yes, I understand that the GitHub action repository is not the repository of golangci-lint itself.
[X] Yes, I've searched similar issues on GitHub and didn't find any.
Your feature request related to a problem? Please describe.
Currently all lint actions show with a severity of error in GitHub Actions. Using the now deprecated github-actions output format was able to differentiate severity levels but this does not appear to be possible with the colored-line-output format.
Describe the solution you'd like.
A new format or amendment to colored-line-output that includes severity and an appropriate problem matcher to extract the severity would work
Describe alternatives you've considered.
Using the github-actions output format, but that seems to be deprecated so I'm not sure how long that would work for.
Additional context.
I noticed the golangci-lint-action problem matcher pattern is different than the go one, and unless the golangci-lint problem matcher is enabled with problem-matchers: true the output doesn't seem to be picked up at all. If the rationale for using colored-line-output with its limitations was that it maintained compatibility with the default go problem pattern matcher then that's seemingly already not the case.
Welcome
Your feature request related to a problem? Please describe.
Currently all lint actions show with a severity of error in GitHub Actions. Using the now deprecated github-actions output format was able to differentiate severity levels but this does not appear to be possible with the colored-line-output format.
Describe the solution you'd like.
Describe alternatives you've considered.
Using the github-actions output format, but that seems to be deprecated so I'm not sure how long that would work for.
Additional context.
I noticed the golangci-lint-action problem matcher pattern is different than the go one, and unless the golangci-lint problem matcher is enabled with
problem-matchers: truethe output doesn't seem to be picked up at all. If the rationale for using colored-line-output with its limitations was that it maintained compatibility with the default go problem pattern matcher then that's seemingly already not the case.