[JENKINS-72970] Allow selecting XUnit in the web interface

[Ririshi]

This adds Parser.XUNIT to the doFillParserItems() method to make it show up (I think) as an option in the web interface with freestyle projects. I've created an issue on JIRA: https://issues.jenkins.io/browse/JENKINS-72970

Doesn't seem to work currently.

I've also found that other places (see below) mentioning Parser.JUNIT but not Parser.NUNIT or Parser.XUNIT. Should those also be included because all of them are test results and not regular code coverage?

coverage-plugin/plugin/src/main/java/io/jenkins/plugins/coverage/metrics/steps/CoverageRecorder.java

Lines 451 to 461 in 50cbf0d

	private String getIcon() {
	var icons = tools.stream()
	.map(CoverageTool::getParser)
	.filter(parser -> parser != Parser.JUNIT)
	.map(Parser::getIcon)
	.collect(Collectors.toSet());
	if (icons.size() == 1) {
	return icons.iterator().next(); // unique icon
	}
	return ICON;
	}

coverage-plugin/plugin/src/main/java/io/jenkins/plugins/coverage/metrics/steps/CoverageRecorder.java

Lines 539 to 546 in 50cbf0d

	private List<ModuleNode> extractTests(final Map<Parser, List<ModuleNode>> results) {
	if (results.containsKey(Parser.JUNIT)) {
	return results.remove(Parser.JUNIT);
	}
	else {
	return List.of();
	}
	}

Testing done

Automated test only

Submitter checklist

Preview Give feedback

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

[github-actions]

• Surviving mutants in this change: 1
• Killed mutants in this change: 0

class	surviving	killed
io.jenkins.plugins.coverage.metrics.steps.CoverageTool$CoverageToolDescriptor	1	0

See https://pitest.org/

[uhafner]

Actually, in the selection list of the available parsers it would make sense to show all parsers. Can you replace that with a lop (stream) of Parser.values(), then this will not happen again?

[uhafner]

Thanks for your PR!

Actually the other testing parsers are not really integrated and tested right now. It was a prototype for JUnit and Java coverage tools to map test cases to coverage information.

So in particular:

coverage-plugin/plugin/src/main/java/io/jenkins/plugins/coverage/metrics/steps/CoverageRecorder.java

Lines 539 to 546 in 50cbf0d

	private List<ModuleNode> extractTests(final Map<Parser, List<ModuleNode>> results) {
	if (results.containsKey(Parser.JUNIT)) {
	return results.remove(Parser.JUNIT);
	}
	else {
	return List.of();
	}
	}

For this to work the enum should be extended: we should distinguish between tests and coverage results. Then we do not need to check for the exact enum value. Maybe a boolean enum (TEST, COVERAGE) as property?

coverage-plugin/plugin/src/main/java/io/jenkins/plugins/coverage/metrics/steps/CoverageRecorder.java

Lines 451 to 461 in 50cbf0d

	private String getIcon() {
	var icons = tools.stream()
	.map(CoverageTool::getParser)
	.filter(parser -> parser != Parser.JUNIT)
	.map(Parser::getIcon)
	.collect(Collectors.toSet());
	if (icons.size() == 1) {
	return icons.iterator().next(); // unique icon
	}
	return ICON;
	}

I think here the same boolean property in the enum could work. In practice the idea was to have a step that collets coverage and tests and shows the results below the coverage-icon. So the tests are ignored for the icon.

But in theory, one could specify a step with tests only. I'm not sure if it makes sense to take care of that as well.

[Ririshi]

Thanks for the feedback. I tried to package the plugin locally and try it on my own Jenkins instance, but it seemed like the web UI broke, the post-build options for Coverage plugin were no longer visible in the list. Not sure if I didn't package and install it correctly or if my code change broke something.

Either way, I will add the extra enum property and update the doFillParserItems method to include all options, for now. Perhaps you could (help me) test the plugin after that?

Edit: In the extractTests method, there's an assumption that there is only one test parser. Unless I change the return type to Map<Parser, List<ModuleNode>> it won't be possible to return the ModuleNodes for each parser separately. How should this be tackled? Also, is the PIT parser used for coverage or for tests? I'm confused about that.
I'm mostly uninitiated in the rest of the codebase (or any Jenkins code at all, for that matter), so I'm hoping you can point me in the right direction :)

[Ririshi]

Looks like I broke something now. I'm using VSCode and it's not a great IDE the way I have things set up right now. I think the new version of extractTests is returning too many tests now (twice the expected number), so I think there might be some kind of duplication going on in the Parser -> ModuleNodes map. I can't really debug this right now as I have no clue (yet) how to run the plugin in debug mode with my local Jenkins instance.

[uhafner]

I think my algorithm of test case mapping is broken 🙈

I am mapping test cases to the test cases, this makes no sense. So you get 8 test cases from 4 test cases now. I think I need to fix that part in the model first. Mapped tests should be removed from the tree, otherwise they count twice.

[uhafner]

Suggested change

	PIT(Messages._Parser_PIT(), ParserType.TEST,
	PIT(Messages._Parser_PIT(), ParserType.COVERAGE,

[github-actions]

• Surviving mutants in this change: 28
• Killed mutants in this change: 0

class	surviving	killed
io.jenkins.plugins.coverage.metrics.steps.CoverageRecorder	23	0
io.jenkins.plugins.coverage.metrics.steps.CoverageTool$CoverageToolDescriptor	4	0
io.jenkins.plugins.coverage.metrics.steps.CoverageTool$Parser	1	0

See https://pitest.org/

[github-actions]

• Surviving mutants in this change: 23
• Killed mutants in this change: 0

class	surviving	killed
io.jenkins.plugins.coverage.metrics.steps.CoverageRecorder	18	0
io.jenkins.plugins.coverage.metrics.steps.CoverageTool$CoverageToolDescriptor	4	0
io.jenkins.plugins.coverage.metrics.steps.CoverageTool$Parser	1	0

See https://pitest.org/

[github-actions]

• Surviving mutants in this change: 23
• Killed mutants in this change: 0

class	surviving	killed
io.jenkins.plugins.coverage.metrics.steps.CoverageRecorder	18	0
io.jenkins.plugins.coverage.metrics.steps.CoverageTool$CoverageToolDescriptor	4	0
io.jenkins.plugins.coverage.metrics.steps.CoverageTool$Parser	1	0

See https://pitest.org/

[Ririshi]

Cheers! Thanks for picking this up. I'm going to try it out with xunit output soon when I get a chance.

[jonesbusy]

Would have been nice to separate the update of the coverage model to an other PR or at least make sure it appear on the release notes

I think it cause some regression on my side when merging JACOCO and COBERTURA reports for a mono-repo application

[uhafner]

Normally I am inlining the changes of the coverage-model. In this case the upgrade was required for this PR so I forgot to add it here as well.