Checkstyle reporter

[jonathan-dev]

Added the possibility to export the linting results as checkstyle xml by using the --checkstyle flag on the lint subcommand.
The --teamcity flag takes precidence over --checkstyle.

The xml contents are written to stdout and thus can be forwarded to a file without containing the logs which are send to stderr (using 1>).

This feature was implemented in order to work with the jenkins warnings plugin

[jonathan-dev]

#606

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 70.96774% with 27 lines in your changes missing coverage. Please review.

Project coverage is 95.01%. Comparing base (b4eac86) to head (70ff2c8).
Report is 31 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/reporter/checkstyle.go	82.35%	6 Missing and 6 partials ⚠️
cmd/pint/ci.go	0.00%	8 Missing and 1 partial ⚠️
cmd/pint/lint.go	62.50%	3 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1129      +/-   ##
==========================================
- Coverage   95.16%   95.01%   -0.15%     
==========================================
  Files         102      103       +1     
  Lines       10235    10355     +120     
==========================================
+ Hits         9740     9839      +99     
- Misses        346      360      +14     
- Partials      149      156       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[prymitive]

Added the possibility to export the linting results as checkstyle xml by using the --checkstyle flag on the lint subcommand.

I, in general, don't want to add code that integrates with something that we don't run ourselves, as it just makes it impossible to refactor that code in the future.
I'm fine with adding a new reporter like this, as it's pretty much self contained, but only if it has good test coverage, which this one does.

The --teamcity flag takes precidence over --checkstyle.
The xml contents are written to stdout and thus can be forwarded to a file without containing the logs which are send to stderr (using 1>).

You need a file at the end, so why not make it --checkstyle=path.xml flag and leave --teamcity as is? In theory there could be any number of report files produced in a variety of formats but sending it all to stdout makes it impossible to enable multiple such reporters at once.

[prymitive]

An e2e test like https://github.com/cloudflare/pint/blob/main/cmd/pint/tests/0158_lint_teamcity.txt would be great.

[jonathan-dev]

Added the possibility to export the linting results as checkstyle xml by using the --checkstyle flag on the lint subcommand.

I, in general, don't want to add code that integrates with something that we don't run ourselves, as it just makes it impossible to refactor that code in the future. I'm fine with adding a new reporter like this, as it's pretty much self contained, but only if it has good test coverage, which this one does.

The --teamcity flag takes precidence over --checkstyle.
The xml contents are written to stdout and thus can be forwarded to a file without containing the logs which are send to stderr (using 1>).

You need a file at the end, so why not make it --checkstyle=path.xml flag and leave --teamcity as is? In theory there could be any number of report files produced in a variety of formats but sending it all to stdout makes it impossible to enable multiple such reporters at once.

I change --checkstyle to be a string flag

[jonathan-dev]

An e2e test like https://github.com/cloudflare/pint/blob/main/cmd/pint/tests/0158_lint_teamcity.txt would be great.

I created a test I am not comparing stderr because it was giving me trouble because of #20 and i don't think it is relevant.

[prymitive]

Create a checkstyle xml formatted report of all problems to this path. ?

[prymitive]

Same here
Close() might error out so we should check for that

[prymitive]

encoding/xml can generate the entire XML file for you, that should be safer & more correct than manually crafting it.

[jonathan-dev]

Sorry here I am not sure what you are referring to exactly. I see I could be using xml.Header.
Do you mean by having a custom struct that marshals to <checkstyle version='4.3'> making dirs marshal to <file name=.... and report to ?

[prymitive]

this doesn't have to be exported, does it?