-
Notifications
You must be signed in to change notification settings - Fork 1
Conversation
* support staticcheck * save report to JSON * generate TOML files for each issue * use a markdown parser for parsing issue descriptions
Using TOML files. |
* integration tests for analyzers * parse triggers using tree-sitter * utilities for working with tree-sitter * staticcheck trigger for tree-sitter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Make the CLI runner more robust (handle stderr, stdout and also allow safe exits in case of non-zero exit codes).
- Processor (takes the result from the CLI output, and converts it to our format): The processor should receive an io.Reader interface, and return the report.
- Reporter (takes in the report in our format, and returns a io.Writer): Return an io.Writer to
Run
andRun
should write it to the desired location. - Processors:
a. Do not write processors for specific CLI formats. Add support for the common ones, likepep8
,emacs
,go vet
,go-ruleguard
etc.
b. Processor should be specified in the struct. - Specifying issues:
a. Use a single issues.toml:
[[issues]]
code = "U1000"
description = """
This is **an** issue.
"""
[[issues]]
code="compile"
...
- Add support for more languages in tree-sitter comment parser.
- Reorganize the code.
* add unit tests * update SDK structure * clean analyzer fields * add unix processor * add utilities
* test TOML generation and verify content * add workflow for running tests
refactor(*): refactor SDK and add tests
Can you add a |
* use environment variable based exporting * use named groups for RegexProcessor
* guide for writing CSS analyzer * add issueProcessor
* add integration test for CSS using csslint * cleanup tests
* refactor tests * add guide for testing analyzers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@burntcarrot Write unit tests. Since this SDK lot of data wrangling, not writing unit tests will cause a lot of maintainability issues.
Added unit tests; ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed half of the code and there is a significant amount of refactoring pending on this. Will review the remaining files once the existing issues have been addressed.
} | ||
|
||
// readMarkdown is a helper utility used for parsing and sanitizing markdown content. | ||
func readMarkdown(content string) (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
content can be accepted as a byte array..
} else { | ||
issue.IssueCode = issueCodeGenerator(content) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: Do we need this else block? Does it improve readability by much? @sourya-deepsource
tree-sitter