As of a couple of weeks ago, when i look at a the coverage for a Java file in a PR, the new code is no longer highlighted at all. Above the file it tells me the percentage of new code covered, but the file itself no longer contains the blue highlights on the new code lines. This is very frustrating. As far as we are aware, we have changed no settings recently in our Sonarqube cloud instance.
2 Likes
Hi,
Weāve been making some tweaks to the UI lately. Would you mind sharing a screenshot, redacted an necessary, showing this?
Also, just to be clear, new code seems properly accounted for in terms of metrics and what issues are new. Itās just the display, right?
Thx,
Ann
it would be difficult to redact the file, as it would be most of the text. thereās not much to show. everthing in the file looks fine except that there is no blue highlighting of the new code (so it just looks like a coverage file with no new code in it).
and yes, everything seems to be working correctly in terms of tracking coverage on new code and displaying the general coverage of the file. it is purely a display problem.
Any news on this? We have the same situation.
I know for a fact that the code from the screenshot is new, but it is only showing the uncovered bar.
Hi,
Iām going to flag this for the team.
Ann
2 Likes
Ha, Iām glad I found this post! I thought I was losing it. This used to have a light blue highlight:
Iāve heard feedback that the light blue was very hard to see before. It was pretty hard to find new lines of code in the UI. Especially if the file is long; it would be nice to have a way to jump to the next block of uncovered code.
1 Like
oh, man, having the ability to jump to the next block of new code or uncovered code would be phenomenally useful for large files. that said, iād just be happy to get the highlighting back right now.
It affects my company as well. When can a fix be expected? Browsing line coverage without this feature makes sonar code coverage completely useless for us. How can such a simple feature be broken for almost 7 days without a fix???
1 Like
Hi all,
I flagged this for the team a couple days ago, but with this many folks confirming the problem, Iāve decided to escalate a bit.
So help me out with some scoping:
Is this in the context only of PRs? In branches? Both?
Is there anywhere (analyzed recently) that you do still see the new code highlighting?
Thx,
Ann
Hi all. Apologies for the disruption. The code causing this problem has been reverted, so you should no longer be experiencing these issues. Please let us know if you still see unexpected behavior.
2 Likes
thanks, seems to be working again now!
1 Like
and now it is broken again.
Hi @James_Ahlborn,
Could you share
- Whether youāre doing a shallow clone?
- What your New Code definition is?
- Whether weāre talking about branch or PR analysis?
Thx,
Ann
this is the same situation as before. looking at the code coverage for individual files in a PR analysis is not showing the blue ānew codeā highlighting.
Hi @James_Ahlborn,
Yes, I understand what youāre (not) seeing is the same as before. We had trouble debugging this the first time so we simply rolled back the underlying change. This time weād like to get the data to understand the underlying problem. So could you help us out here?
I guess weāre talking about a PR analysis. And New Code is the changes since the branch. Whenās the last time you analyzed the branch itself?
And can you tell us about your checkout?
Thx,
Ann
yes, as i said, this is a PR analysis. i donāt know what you mean by āwhenās the last time you analyzed the branch itselfā? the checkout is a full git checkout (sorry i missed that in my last answer).
1 Like
Hi,
On SonarQube Cloud PR analysis is to some degree compared to the target branch. Thatās why Iām asking about the branch analysis. It may only be relevant in a ānew issuesā context, but Iām trying to gather as much data as possible.
To be transparent here,
- we rolled out a change
- yāall reported problems
- we rolled it back
- we failed to diagnose the problem
- weāve rolled the change back out in a bid to collect more information so we can truly fix it this time.
Iām sorry I was a bit coy about it earlier. I was hoping some of the folks directly involved would give these explanationsā¦ 
Purely FYI, Iām about to head out for the holidays, but AFAIK the relevant folks are paying attention to this thread. Hopefully theyāll get the data they need soon to get this solved.
And along those lines, would you mind adding -Dsonar.verbose=true to your analysis command line, running the analysis again, and then posting those logs, redacted as necessary, starting from the analysis command itself?
Thx,
Ann
Hi, James!
Again, Iām sorry for the disruption. Iāll DM you for specific project information so I can more precisely understand the issue. Hopefully, this will be the key to resolving the bug for everyone in this thread.
-Stuart
We have identified the issue (the wrong fieldname was specified in an API contract). We have a code fix implemented and tested, but due to our internal end-of-year code freeze, we will not be able to deploy this fix for a couple weeks.
I will update this thread when the fix is live. Thanks for your patience.
1 Like
Any news?
This bug is really interfering with our work and we canāt figure out which lines are missing tests.