It would be great if it would be possible to produce results in multiple formats of a run.
This can be useful if you e.g. want to run golangci-lint in CI and send a human-readable output (line-number) in a plain-text report to the user and also have a checkstyle result to process it and show it in the CI tool.
Syntax could be like:
golangcilint run --out-format <FORMAT>:(<FILENAME>|stdout|stderr)[,<FORMAT>:(<FILENAME>|stdout|stderr)]..
Hi!
Looks useful. But I'm interested: did you check existing output formats?
I'm using it in GitLab CI. It displays the stdout in the web interface, and that's the easiest way to see it, but it also accepts the Code Climate output format to keep track of the differences and display how the code improved or regressed in code quality in a merge request. I'm currently doing something like
echo '[]' > codeclimate.json
golangcilint run || golangcilint run --out-format codeclimate > codeclimate.json
So it runs once if everything is good, but runs twice to generate the non empty code climate report otherwise.
Likewise, it would be useful to have stdout show an easy to read output, and additional output to a file for CI to digest
@jirfag
Looks useful. But I'm interested: did you check existing output formats?
Yes, it's not possible to generate output of a single run in multiple formats, is it? :-)
got it, I didn't understand it properly first
+1, very useful as our CI has junit support but we also want standard output
:+1: was looking for this as well (logging in human-readable format, and write a junit.xml for Jenkins).
One comment on the proposed format;
--out-format <FORMAT>:(<FILENAME>|stdout|stderr)[,<FORMAT>:(<FILENAME>|stdout|stderr)]..
Using colons (:) and commas as separators could be problematic (e.g, Windows paths will have a colon for the drive-letter, and commas (although unlikely) are valid in filenames. Not _impossible_ to solve, but good to keep in mind.
Alternatives worth considering;
--out-format for stderr/stdout, and introduce a new flag for writing to a file (e.g., --output-file junit-xml=C:\foo\junit-report.xml)--output-file flags can be specified, so that no comma separator is needed--junitfile=/path/to/junit-report.xml (this will introduce many more flags, which may be undesirable)This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Dear stale bot,
please do not close this issue.
Best wishes,
Fabian
We can add out-formats as a map option out-format: out-file. But it will be a bit complicated to parse it from command line.
Latest golangci-lint version use caching. Maybe it's better for us to focus on sub-second overhead for repeated runs? If we achieve that we can just run golangci-lint multiple times.
I think improving caching is definitely more important and running golangci-lint per output might be ok for a lot of users.
We are running golangci-lint per application in a monorepository with ~50x Go-Applications.
In the worst case CI runs the checks for all Go-Applications in a branch.
This would mean to have to run golangci-lint 100 times instead of 50x.
It feels hackish to me to rerun it per output-format without explicit support to only create another report for the last run.
I don't have any numbers to evaluate how big the overhead would be to judge if it really matters, though.
Most helpful comment
:+1: was looking for this as well (logging in human-readable format, and write a junit.xml for Jenkins).
One comment on the proposed format;
Using colons (
:) and commas as separators could be problematic (e.g, Windows paths will have a colon for the drive-letter, and commas (although unlikely) are valid in filenames. Not _impossible_ to solve, but good to keep in mind.Alternatives worth considering;
--out-formatfor stderr/stdout, and introduce a new flag for writing to a file (e.g.,--output-file junit-xml=C:\foo\junit-report.xml)--output-fileflags can be specified, so that no comma separator is needed--junitfile=/path/to/junit-report.xml(this will introduce many more flags, which may be undesirable)