Improve detection of paths in GO_COV reports by akash-manna-sky · Pull Request #265 · jenkinsci/coverage-model

akash-manna-sky · 2026-01-28T18:35:13Z

GO_COV issues with resolving paths

Issue #263 reported that Go coverage reports were losing their directory structure and failing to locate source files. For example, example.com/project/internal/alpha.go was incorrectly parsed as just alpha.go. To resolve this, I implemented a ModuleRegistry() solution that parses go.mod files to extract module-to-directory mappings. It then uses a longest-prefix matching approach to accurately translate coverage paths to file system paths (e.g., ext/sum.go → ./hack/ext/sum.go). When go.mod files are not available, the implementation falls back to intelligent heuristics to infer the correct path structure.

From the demo coverage profile:

ext/sum.go                    => ./hack/ext/sum.go
ext/stat/minmax.go       => ./hack/ext/stat/minmax.go
ext/sub/sub.go              => ./hack/extsub/sub.go
hello.test/main.go         => ./main.go
hello.test/cpu/main.go  => ./cpu/main.go

Fixes #263

Testing done

Submitter checklist

Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
Ensure that the pull request title represents the desired changelog entry
Please describe what you did
Link to relevant issues in GitHub or Jira
Link to relevant pull requests, esp. upstream and downstream changes
Ensure you have provided tests that demonstrate the feature works or the issue is fixed

…t cases

…GoCovParser

… path parsing

… improve asInt method

uhafner

Looks good, I will ask in #263 if we might get a more realistic report example.

uhafner · 2026-02-12T10:13:23Z

+    private String buildPackagePath(final List<String> parts, final int startIndex) {
+        return parts.subList(startIndex, parts.size() - 1).stream()
+                .collect(Collectors.joining("."));


Replace with

String.join(".", parts.subList(startIndex, parts.size() - 1));

And extract "." as parameter so you don't need to duplicate with "/"

uhafner · 2026-02-12T10:13:59Z

+        if (parts.size() == 1) {
+            return new PathInfo(StringUtils.EMPTY, StringUtils.EMPTY, 0);
+        }
+        if (parts.size() == PATH_LENGTH_TWO) {


Suggested change

if (parts.size() == PATH_LENGTH_TWO) {

if (parts.size() == 2) {

uhafner · 2026-02-12T10:14:26Z

+        if (parts.size() == PATH_LENGTH_TWO) {
+            return new PathInfo(parts.get(0), parts.get(0), 1);
+        }
+        if (parts.size() == PATH_LENGTH_THREE) {


PMD is sometimes too silly: add a suppression for this method.

Suggested change

if (parts.size() == PATH_LENGTH_THREE) {

if (parts.size() == 3) {

uhafner · 2026-02-12T10:18:04Z

+                    var module = new ModuleNode(moduleName);
+                    modules.add(module);
+                    return module;


While that seems to work technically, it is a bad practice to modify the elements of the parameter.

Can you add the result in the caller?

This one still is open? Never ever change a parameter.

…dling

uhafner · 2026-02-12T13:25:38Z

Can you check, if the new example in #263 works?

…overage profile test

…er handling of path parts

egonelbre · 2026-02-12T15:05:02Z

+    }
+
+    @SuppressWarnings("PMD.AvoidLiteralsInIfCondition")
+    private PathInfo determinePathStructure(final List<String> parts) {


This logic does not look correct, because the module name can be from "a" to "a/b/c/d/e/f/g" etc. The only way to determine what it actually is, is based on the information parsed from go.mod.

PS: this approach as a fallback when go.mod is not available would be of course fine.

egonelbre · 2026-02-12T15:05:47Z

+ext/stat/minmax.go:9.27,11.3 1 1
+ext/stat/minmax.go:12.2,12.24 1 1
+hello.test/main.go:3.13,5.2 1 1
+hello.test/cpu/main.go:3.13,5.2 1 1


Note, I updated the example to have an additional corner case for determining, which module to use.

… and update demo coverage profile

akash-manna-sky · 2026-02-12T16:06:40Z

Please have a look. @uhafner

uhafner · 2026-02-12T18:53:11Z

Please have a look. @uhafner

Did you have a chance to look at the comments from @egonelbre?

akash-manna-sky · 2026-02-12T19:03:51Z

Please have a look. @uhafner

Did you have a chance to look at the comments from @egonelbre?

Yes, I looked his concern. My approach is basically heuristic-based approach. I was waiting for your suggestion. Anyway, I have a plan, will push the changes shortly.

egonelbre · 2026-02-12T19:08:38Z

@akash-manna-sky https://github.com/egonelbre/exp/blob/main/coverage_example/parse/main.go contains Go code on how to handle module files and use them to parse coverage. Extracting the module name can be done via regex easily as well, because the go.mod doesn't have block comments.

…path resolution and enhance path parsing logic

…plitting and improve go.mod parsing logic

…module registry initialization

akash-manna-sky · 2026-02-13T07:39:44Z

Please review the changes @uhafner

akash-manna-sky · 2026-03-04T13:54:23Z

Is there anything need to update? Please review. @uhafner

uhafner

Looks almost good now. I still find a hard to see what is working now differently. Can you please add more text to the description in the PR as the current text does not say anything useful for users.

uhafner · 2026-03-04T15:24:07Z

    private static final long serialVersionUID = -4511292826873362408L;

    private static final PathUtil PATH_UTIL = new PathUtil();
+    private static final Pattern PATH_SEPARATOR = Pattern.compile("/");


This makes no sense, see below.

uhafner · 2026-03-04T15:25:47Z

-        if (org == null) {
+    private String determineContainerName(final String fullPath) {
+        var normalizedPath = fullPath.replace('\\', '/');
+        var parts = Arrays.stream(PATH_SEPARATOR.split(normalizedPath)).toList();


Suggested change

var parts = Arrays.stream(PATH_SEPARATOR.split(normalizedPath)).toList();

var parts = StringUtils.split(normalizedPath, PATH_SEPARATOR);

uhafner · 2026-03-04T15:26:19Z

+        if (parts.isEmpty()) {
            return StringUtils.EMPTY;
        }
-        return org + "/";
+
+        if (parts.size() >= 3 && parts.get(0).contains(".")) {
+            return parts.get(0) + "/" + parts.get(1);
+        }
+
+        return parts.get(0);


It makes no sense to convert to a list, just use the array

uhafner · 2026-03-04T15:27:04Z

+                    var module = new ModuleNode(moduleName);
+                    modules.add(module);
+                    return module;


This one still is open? Never ever change a parameter.

uhafner · 2026-03-04T15:28:16Z

+            return createPathPartsFromModule(normalizedPath, moduleMatch);
+        }
+
+        var parts = Arrays.stream(PATH_SEPARATOR.split(normalizedPath)).toList();


…ling and simplify module retrieval logic

akash-manna-sky · 2026-03-04T17:26:44Z

I added a short PR description regarding this PR. I also implemented your requested changes. Please review the changes. @uhafner

uhafner · 2026-03-04T19:58:49Z

+         * Creates an empty module registry.
+         */
+        ModuleRegistry() {
+            this.modules = new ArrayList<>();


The module registry does not make sense. It has a list of modules that is always empty. Can you check what the registry is good for?

…ath handling

…sWarnings

…sWarnings annotation

egonelbre

It looks like the latest change completely removes the module handling code, without module handling an accurate path cannot be resolved.

I should mention there does not seem to be any tests for having multiple module files and a corresponding coverprofile. This should make it easier to see when essential pieces are being removed.

https://github.com/egonelbre/exp/tree/main/coverage_example/demo contains a decent example that should work with the expected output shown in #263 (comment)

akash-manna-sky · 2026-03-05T13:53:26Z

What should I do now? @uhafner

uhafner · 2026-03-05T14:01:16Z

What should I do now? @uhafner

Did you already have a look at the example?
https://github.com/egonelbre/exp/tree/main/coverage_example/demo

Does your code correctly resolve the files?

I did not find time yet to make me familiar with the reports. Maybe it makes sense to go a step back and re-evaluate the problem? I try to find some time to look into the problem a little be deeper.

uhafner · 2026-03-05T14:04:20Z

Another option would be to ask in the corresponding channels of the GoCov project, how the mapping should be and why they do not include the corresponding information in the report format. All other coverage tools in the world report their files correctly with absolute or relative paths, I see no reason why GoCov should not follow the same approach.

egonelbre · 2026-03-05T15:00:41Z

The relevant change was done in https://go-review.googlesource.com/c/go/+/122478. The main reasoning for using package path instead of filenames is that a lot of go tooling use package path as input. Also, the package path allows to transfer the coverprofile to other computers and have it still correctly resolve to correct absolute path (assuming you are on the exact same commit).

As for finding the correct mapping -- one approach I didn't think of earlier is to let people build the "module name" -> "directory" mapping with go list, e.g.

$ go list -m -f "{{.Path}} >> {{.Dir}}" all

// example output from my command
hello.test >> /Users/egon/code/github.com/egonelbre/exp/coverage_example/demo
ext >> /Users/egon/code/github.com/egonelbre/exp/coverage_example/demo/hack/ext
ext/sub >> /Users/egon/code/github.com/egonelbre/exp/coverage_example/demo/hack/extsub

// but it may also contain things from module cache
loov.dev/diagram >> /Users/egon/go/pkg/mod/loov.dev/diagram@v0.0.0-20250912145245-d31ac3c2406b

Of course that would be a little bit more inconvenient to setup than passing in the relevant go.mod files. The conversion logic from package path to absolute path would still stay the same though as I previously suggested.

akash-manna-sky · 2026-03-06T19:40:04Z

What should I do now? @uhafner

Did you already have a look at the example? https://github.com/egonelbre/exp/tree/main/coverage_example/demo

Does your code correctly resolve the files?

I did not find time yet to make me familiar with the reports. Maybe it makes sense to go a step back and re-evaluate the problem? I try to find some time to look into the problem a little be deeper.

Yes, it seems my code resolve the files. And please take your time and look into the problem. I will commit the changes after your suggestions. I am trying to figure out the solutions and looking into the ModuleRegistry() method more deeply to figure out what the best approach might be. Thanks!

egonelbre · 2026-08-05T08:43:40Z

+        assertThat(report.getAllFileNodes()).map(FileNode::getFileName).containsExactlyInAnyOrder(
+                "sum.go", "minmax.go", "main.go", "main.go");
+    }
 }


It looks like the test case I outlined in #263 (comment) is missing. Similarly I don't see any go.mod in the testsuite or module parsing, which are necessary to correctly resolve paths.

…t coverage

github-actions · 2026-08-15T07:50:41Z

☀️ Quality Monitor

Tests

Unit Tests: ✅ successful — 453 passed $\color{green}{\textsf{(+11)}}$
⛔ Architecture Tests: ✅ successful — 10 passed $\textsf{(±0)}$

Coverage for New Code

   〰️ Line Coverage: 97.35% — 4 missed lines
   ➰ Branch Coverage: 100.00% — perfect 🎉
   Mutation Coverage: 92.86% — 5 survived mutations
   💪 Test Strength: 100.00% — perfect 🎉

Coverage for Whole Project

   〰️ Line Coverage: 95.96% $\color{green}{\textsf{(+0.02)}}$ — 132 missed lines
   ➰ Branch Coverage: 91.68% $\color{green}{\textsf{(+0.21)}}$ — 115 missed branches
   Mutation Coverage: 89.74% $\color{green}{\textsf{(+0.09)}}$ — 165 survived mutations
   💪 Test Strength: 92.80% $\color{green}{\textsf{(+0.05)}}$ — 112 survived mutations in tested code

Style

   CheckStyle: No warnings $\textsf{(±0)}$
   PMD: No warnings $\textsf{(±0)}$
   ☕ Java Compiler: No warnings $\textsf{(±0)}$

Bugs

SpotBugs: No bugs $\textsf{(±0)}$
🐛 Error Prone: No bugs $\textsf{(±0)}$

API Problems

🚫 Revapi: No warnings $\textsf{(±0)}$

Vulnerabilities

🛡️ OWASP Dependency Check: No vulnerabilities $\textsf{(±0)}$

Software Metrics

   🌀 Cyclomatic Complexity: 1019 (total)
   💭 Cognitive Complexity: 782 (total)
   ➿ N-Path Complexity: 1578 (total)
   📏 Lines of Code: 10279 (total)
   📝 Non Commenting Source Statements: 4103 (total)
   🔗 Class Cohesion: 54.55% (maximum)
   ⚖️ Weight of Class: 100.00% (maximum)

📌 Reference Results

Delta reports computed against the reference results of 20d104b in workflow run 31372098981.

🚦 Quality Gates

Overall Status: ✅ SUCCESS

✅ Passed Gates

✅ Overall Tests Success Rate: 100.00 >= 100.00
✅ Line Coverage in New Code: 97.35 >= 90.00
✅ Branch Coverage in New Code: 100.00 >= 90.00
✅ Mutation Coverage in New Code: 92.86 >= 90.00
✅ Potential Bugs in Whole Project: 0.00 <= 0.00
✅ Style Violation in Whole Project: 0.00 <= 0.00

Created by Quality Monitor v4.15.0 (#82d77af). More details are shown in the GitHub Checks Result.

akash-manna-sky added 6 commits January 27, 2026 10:02

Enhance GoCovParser to support simple paths and add corresponding tes…

3eef5d4

…t cases

Improve documentation for parseGoPath method and PathParts record in …

27457e4

…GoCovParser

remove unnecessery comments

b0733f0

documentation for LINE_PATTERN and parseGoPath method

6051f01

Refactor GoCovParser to improve coverage data handling and streamline…

851fd12

… path parsing

Refactor GoCovParser to reorganize PathInfo and PathParts records and…

21874c5

… improve asInt method

akash-manna-sky marked this pull request as ready for review January 29, 2026 18:03

uhafner added the bug Bugs or performance problems label Feb 12, 2026

uhafner requested changes Feb 12, 2026

View reviewed changes

uhafner changed the title ~~GO_COV issues with resolving paths~~ Improve detection of paths in GO_COV reports Feb 12, 2026

uhafner mentioned this pull request Feb 12, 2026

GO_COV issues with resolving paths #263

Open

refactor GoCovParser to simplify module creation and enhance path han…

5a0f3a1

…dling

github-actions Bot requested a review from uhafner February 12, 2026 11:17

akash-manna-sky added 2 commits February 12, 2026 19:34

refactor GoCovParser to correct PathInfo instantiation and add demo c…

54e19e1

…overage profile test

refactor GoCovParser to enhance PathInfo instantiation logic for bett…

fbd7d4c

…er handling of path parts

egonelbre reviewed Feb 12, 2026

View reviewed changes

refactor GoCovParser to remove unnecessary suppression of PMD warning…

63b59fd

… and update demo coverage profile

akash-manna-sky added 3 commits February 13, 2026 00:40

refactor GoCovParser to introduce ModuleRegistry for accurate module …

250c759

…path resolution and enhance path parsing logic

refactor

421f5b5

refactor GoCovParser to replace Arrays.asList with Streams for path s…

c4aaab8

…plitting and improve go.mod parsing logic

egonelbre reviewed Feb 12, 2026

View reviewed changes

Comment thread src/main/java/edu/hm/hafner/coverage/parser/GoCovParser.java

akash-manna-sky added 2 commits February 13, 2026 01:47

refactor

92cd07e

refactor GoCovParser to enhance deserialization handling and improve …

cdcb87c

…module registry initialization

github-actions Bot requested a review from uhafner March 2, 2026 18:58

akash-manna-sky added 2 commits March 3, 2026 13:55

removed usused methods and simplyfy the GoCovParser

8ecd45f

remove unused GO_MOD_MODULE_PATTERN from GoCovParser

d873657

uhafner requested changes Mar 4, 2026

View reviewed changes

refactor GoCovParser to replace Arrays with StringUtils for path hand…

2726ae9

…ling and simplify module retrieval logic

github-actions Bot requested a review from uhafner March 4, 2026 16:44

fix one PMD warning

7bada57

Merge branch 'main' into issue-263

fadcc2b

uhafner reviewed Mar 4, 2026

View reviewed changes

refactor GoCovParser to remove ModuleRegistry and related logic for p…

2805fa7

…ath handling

github-actions Bot requested a review from uhafner March 5, 2026 04:56

remove unnecessary suppression PMD.CouplingBetweenObjects in @Suppres…

51c0e4f

…sWarnings annotation

egonelbre reviewed Mar 5, 2026

View reviewed changes

fix check style warning

a0ce03b

uhafner marked this pull request as draft March 31, 2026 20:53

akash-manna-sky added 2 commits April 19, 2026 17:35

Merge branch 'main' into issue-263

7274133

Merge branch 'main' into issue-263

6e1e68b

akash-manna-sky marked this pull request as ready for review August 4, 2026 05:17

egonelbre reviewed Aug 5, 2026

View reviewed changes

akash-manna-sky added 2 commits August 15, 2026 12:19

Merge branch 'main' into issue-263

4d378ca

Enhance GoCovParser to support module path resolution and improve tes…

70db9ec

…t coverage

akash-manna-sky requested a review from egonelbre August 15, 2026 07:45

	if (parts.size() == PATH_LENGTH_TWO) {
	if (parts.size() == 2) {

	if (parts.size() == PATH_LENGTH_THREE) {
	if (parts.size() == 3) {

	var parts = Arrays.stream(PATH_SEPARATOR.split(normalizedPath)).toList();
	var parts = StringUtils.split(normalizedPath, PATH_SEPARATOR);

Uh oh!

Uh oh!

Conversation

akash-manna-sky commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Testing done

Submitter checklist

Uh oh!

uhafner left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

uhafner commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akash-manna-sky commented Feb 12, 2026

Uh oh!

uhafner commented Feb 12, 2026

Uh oh!

akash-manna-sky commented Feb 12, 2026

Uh oh!

egonelbre commented Feb 12, 2026

Uh oh!

Uh oh!

akash-manna-sky commented Feb 13, 2026

Uh oh!

akash-manna-sky commented Mar 4, 2026

Uh oh!

uhafner left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akash-manna-sky commented Mar 4, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

egonelbre left a comment

Choose a reason for hiding this comment

Uh oh!

akash-manna-sky commented Mar 5, 2026

Uh oh!

uhafner commented Mar 5, 2026

Uh oh!

uhafner commented Mar 5, 2026

Uh oh!

egonelbre commented Mar 5, 2026

Uh oh!

akash-manna-sky commented Mar 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Aug 15, 2026

☀️ Quality Monitor

Tests

Coverage for New Code

Coverage for Whole Project

akash-manna-sky commented Jan 28, 2026 •

edited

Loading

uhafner commented Feb 12, 2026 •

edited

Loading