Include `file` and `line` attribute for junit report output format

[hanikesn]

Welcome

• Yes, I've searched similar issues on GitHub and didn't find any.
• I agree to follow this project's Code of Conduct

Your feature request related to a problem? Please describe

Various tools like action-junit-report rely on the file and line testcase attributes in order to report errors nicely inline the file.

file and line testcase attributse are also part of the Common JUnit XML Format:
https://github.com/testmoapp/junitxml?tab=readme-ov-file#complete-junit-xml-example

It'd be nice to include that information in golangci-lint reports as well.

Describe the solution you'd like

Include file and line testcase attributes like so:

<testsuites>
  <testsuite name="go/internal/pkg/set/set_test.go" tests="1" errors="0" failures="1">
    <testcase name="unused" classname="go/internal/pkg/set/set_test.go:15:6" file="go/internal/pkg/set/set_test.go" line="15">
      <failure message="go/internal/pkg/set/set_test.go:15:6: func `unused` is unused" type=""><![CDATA[: func `unused` is unused
Category: unused
File: go/internal/pkg/set/set_test.go
Line: 15
Details: func unused(t *testing.T) {]]></failure>
    </testcase>
  </testsuite>
</testsuites>

Describe alternatives you've considered

Parsing the file and line number from the classname is too brittle.

Additional context

No response

Supporter

• I am a sponsor through GitHub or OpenCollective

[boring-cyborg]

Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.

[ldez]

Hello,

"Common JUnit XML Format" is not a specification but just an attempt to document the format.

There is no official specification for the JUnit XML file format and various tools generate and support different flavors of this format.

file and line are defined in the section "Complete JUnit XML example":

Not all elements are supported by all tools, and not all tools follow and understand the same conventions.

This can be a problem because those attributes are not a part of the "Basic JUnit XML structure".
If a tool validates the format with a strict approach, those fields will produce an error.

[hanikesn]

This can be a problem because those attributes are not a part of the "Basic JUnit XML structure".
If a tool validates the format with a strict approach, those fields will produce an error.

This could easily be avoided by making those opt-out/in.

[ldez]

It's not as easy as you think: the CLI flags don't allow adding options for only one format.

So there are 2 possibilities:

• allow to add an option only with the configuration file
• have a dedicated format

The first possibility will be confusing because this option will only work for one format (on 13 formats), so it is not the right possibility.

The second possibility seems better and it is near existing formats (colored-tab/tab, colored-line-number/line-number)

[hanikesn]

Nice! Thank you!