I’ve read the various threads in here regarding code coverage and how the post 6.x architecture consolidates coverage reporting so you can no longer see where your coverage comes from. No engineering organization that proactively manages quality can reasonably ignore this distinction. I won’t debate this here since this isn’t a feature request post.
I see this ticket where customer questions around visible were redirected to the forum for discussion.
My question is this. What can I do or build to get this data anyways?
I saw the suggestion for a custom metrics option…which is apparently going away.
I saw the suggestion to use a reporting plugin. Will that option be supported long term?
I saw a mention of using labels.I’ve never used these. Can I somehow label coverage such that I can distinguish between which report the data came from at least? How would that work?
The amount of discussion around this in the forums is hopefully getting to a point where you’d reconsider this design change.
We have no plans to remove the ability to write your own, custom plugins.
Labels are applied at project level. Not sure how this would work in your context.
That’s an old version and past EOL. The current version is 8.2 (8.3 drops next week) and the current LTS is 7.9.3. You should upgrade to one of them at your earliest convenience.
Thank you Ann. That helps. Ok I will look in to building a custom plugin then. I’m being asked by various Architects and team members within my company about how they see this. Some remember this data being available from past versions.
Yes, I’m (painfully) aware of how old 7.7 is. The reason we’re so behind on versions is because we have hundreds of repos utilizing sonar…and sonar config isn’t entirely centralized…and when the sonar.branch parameter support went from deprecated to dropped in 7.8, rather the scanner ignoring the unsupported property it fails to run the scan, which blows up the whole pipeline…so we had to uninstall 7.9 and revert back to 7.7.
Now we have to go find all the builds that’ll break before we can safely upgrade again. Open to creative workarounds if you have any, that avoid iterating through all our repos / pipelines to identify which ones will break.
The best option I can think of is forking the scanner and ignoring the property in my own jar as the jar used is set on a per jenkins basis…less work than going through each repo.
I should probably tell you to open a new thread for this, but…
Since the old sonar.branch parameter was basically a hack that set the ‘branch’ key to [project key]:[branch value] the easiest think to do is probably use the web services (docs link in the page footer) to pull a list of project keys and look for the x:y pattern and update those builds.