Migrating to json data handeling #209
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Allows verbose reporting of Issues in Run Terminal/Log. - Correctly maps Issue Severity to GitHub Severity - Additionally adds support for Severity Failure levels (defaults to 'notice' [all]) - Adds suggested fixes to Annotation Raw Details - Prepares foundation for supporting Comments - Adds support for Multi-Line Annotations - Adds mapping for common Issue Severities to GitHub Severities (Code climate | Checkstyle | GitHub) - Adds handeling of 'Ignore' Issue Severity (removes from Issue List) - Adds support for Character Range Annotations
This was surprisingly difficult. This is pretty reliable, using low-cost methods (filtering on Name comparison, Annotation count [we add one, so it should have atleast one]) and then searching for a unique string if the count is still higher than 1. I'm pretty happy about this, I think this will stand the test of time until GitHub get's their act together...
Add a Setup (Pre-Main) action to prepare the Env and begin CheckRun Resolution. With any luck, this will solve that little issue, otherwise I give up.
I have been jumping through way too many hoops to make the non-standard checks on origin behave properly, oh well.
It is indicating it is not getting Check Suite Information, which is unlikely.
|
The PR handles too many topics it's impossible to review it. |
|
I think it's time on close this PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Re-Issue of #207 after fixing CheckRun resolution. All of the same comments apply:
This does a bunch... But also, not that much. In summary, it switches to using the
jsonoutput ofgolangci-lintand handling the formatting and reporting to GitHub inside of the action. This allows for a more flexibility in how the lint issues are handled than simply passing the text output to the Action Log (which is allgolangci-lintwould be able to do). With this approach, the action can resolve a number of issues, and is in a better position to resolve a few more. The active changes in this PR are:Allows verbose reporting of Issues in Run Terminal/Log, regardless of event type
Resolves: github action log output doesn't print the affected file name & line #119
Additionally adds support for Severity Failure levels via
--failure-level(defaults to 'notice' [all])Replaces: Add option to not fail on only Warnings #198
Resolves Discussion: Change staticcheck severity to warning golangci-lint#1853
Adds suggested fixes to Annotation Raw Details
Partially Resolves: Ability to make suggested changes on a PR #35
Prepares foundation for supporting Comments
Related: Support comments instead of annotations #5
Adds mapping for common Issue Severities to GitHub Severities (Code climate | Checkstyle | GitHub)
This avoids a potential issue of having a severity that is not supported by GitHub configured, which, in it's current implementation,
golangci-lintwould just echo, and would not behave as expected in the Action.Adds handling of 'Ignore' Issue Severity (removes from Issue List)
Adds support for Multi-Line Annotations
Adds support for Character Range Annotations
Note on Severity Levels and
ignore: Failure is determined bygolangci-lintexiting with a non-zero code and the Issues List containing at least one Issue with a Severity Level equal to or greater than the setting of--failure-level. This defaults tonotice, and can be one ofnotice,warning, orfailure.Ignore is stripped from the Issues list, and therefore is neither reported to the Log, or grounds for
failure(a run that reports only Issues of severity levelignorewill not fail, even ifgolangci-lintexits with1). It is not possible to set thefailure-leveltoignoreeither. Additionally, it is not possible to not fail on a severity level offailure.With that in mind, this offers a few options on Conditional Failure:
ignore, and you will not see it or fail on it.noticeorwarning, and set--failure-levelto the next severity up.Consideration: I set the default
--failure-leveltonoticebecause, in the current implementation, any Lint Issue can cause a Failure, and I didn't want to change the behavior too much (that being said, handling ofignorealready changes this behavior, but that seemed expected). However, it would make the most sense, semantically, to have the default--failure-levelset towarning. What are your thoughts?As you can see, if the Action has access to the full output, there is a lot that can be done fairly quickly.
With regards to Comments (#5): There is a bit of work that would need to be done to fully do this, but this sets the stage fairly nicely.