[Feature]: JUnit (or JSON) log format

[NoTuxNoBux]

Description

CSharpier can already be run in CI/CD using check as per the documentation, but some CI systems such as GitLab and Jenkins also support JUnit reports directly. It would be nice if there was a --log-format=JUnit or --log-format=JSON to get a structured version of the output rather than a purely textual log.

Supporting JUnit (XML) allows direct ingestion in CI report systems. Alternatively JSON or another structured format also works, but requires all consumers to write their own translation/mapper, which probably is somewhat suboptimal.

The main advantage of JUnit reports is that they can be visualised per-file inline in the CI system, including in merge/pull requests. The developer can then click them open instead of needing to dive into CI output directly (which I've noticed can be nontrivial for some developers that aren't familiar with how CI works and only use it to view results).

[belav]

Supporting JUnit/Json output is non trivial if it is outputting failures for individual files, and I don't see much benefit doing it that way. A failure of csharpier formatting check isn't the same as failing unit tests - you don't need to address the files individually. All you need to do is run dotnet csharpier format .

It does look like it should be pretty easy to treat the entire csharpier check as a pass/fail. A fail would tell you how many files weren't formatted and that you need to run csharpier. That is essentially what I do for my gh actions that check if code is formatted. The action does nothing but check formatting and when it fails it lets you user know what to do.

Something like this

<testsuites tests="1" failures="1" time="1.234">
    <testsuite name="CSharpier" tests="1" failures="1" time="1.234">
      <testcase name="Formatting" classname="CSharpier" time="1.234">
        <failure message="3 files are not formatted"><![CDATA[
  Run `dotnet csharpier format .` and commit the result.
        ]]></failure>
      </testcase>
    </testsuite>
  </testsuites>

One potential downside is if a single CI run is performing a csharpier formatting check for multiple directories. Perhaps including path being checked in the xml is enough.

Otherwise maybe it is simple to wrap the call to csharpier in something that does essentially what I suggested and not make the changes to csharpier.

[NoTuxNoBux]

Indeed, the JUnit format is/was mainly geared at unit tests from what I recall and was then sort of 'promoted' to places where it doesn't necessarily entirely make sense (e.g. there is no concept of warnings, just test failures, IIRC) by CI/CD systems. As a result there might be a little bit of 'abuse' involved into getting things into that specification.

I'm doing the same thing with dotnet build in order to get errors and warnings in a JUnit report, but I believe a JUnit testcase might need to be created per file (and a failure under that testcase if there is at least one error), or the files/errors won't show up per file in some CI/CD systems - though the rest of your example looks like it would indeed work.

The main reason to support JUnit directly would be direct support for CI/CD systems, such as the test results overview in at least GitLab and Jenkins. Jenkins can also show trends of these failures across time - IIRC there is no way past JUnit for this.

Alternatively if something like JSON or XML output were to be supported, it would already be easier to parse than the current text-based output format, since it's less structured. In turn converting that into JUnit XML isn't that difficult using a custom Python script in CI/CD or similar, if that sounds more appropriate for CSharpier. Of course with the downside that everyone that wants this needs to do so manually and write the same code.