If yes, this is REALLY blocking for us, because it would mean that we can easily introduce a high severity issue, without any (automated) control until we reach the main branches?
As I understand it, you’re reporting multiple problems here:
my PR was not decorated(?)
expected issues weren’t raised
I get a warning on the branch homepage
It’s really best to keep it to one issue per thread, but I understand that you might not have realized it was multiple different things so I’m going to try to address them all here. But if we have to go in-depth, we’re really going to need to split these topics.
Those values must be set server-side. PR decoration is triggered asynchronously from the server at the end of analysis report processing, and those analysis parameters are no longer in scope when decoration would happen. So you’re looking at a PR analysis with no information about where decoration should take place. Therefore, it doesn’t.
2nd item…
What rule do you expect to raise an issue on the code sample you provided? Nothing is jumping out at me.
3rd item…
The warning you’re seeing on the homepage is purely about metrics in the quality gate and is entirely unrelated to issues. All new issues will always be reported, regardless of how many or how few new lines there are. But when you have only 1 new line and it’s uncovered, then you have 0% coverage. If that line is difficult to cover, then you’re stuck with un-mergable/releasable code. So we don’t fail the quality gate for coverage (or duplications?) when there are fewer than 20 new lines.
Thank you for the detailed answer. We’ve been struggling on our own for some time with all those issues and I’ll try to focus on the first item (PR decoration missing).
we’ve set sonar.pullrequest.bitbucketserver.project and sonar.pullrequest.bitbucketserver.repository server side
Still the link is not established. At least for this project, for other, it works like a charm
I was wondering about the sonar.scm.revision parameter: it’s not documented anywhere and when we remove it, we had errors like the “Git commit was missing”. Is that something we really need to do?
Regarding sonar.scm.revision, I can’t give you any details because I don’t think I’d even heard of it before this thread. At a guess you’ve sussed-out one of the internal parameters normally set by analysis. If I’m correct, the fact that things go sideways when you don’t set the value manually means that the underlying parameters still aren’t correct.
So let’s talk about your checkout. Are you analyzing the PR branch or a merge branch? Also, you’re not doing a shallow clone, are you?
We scan a PR and the checkout is performed by Jenkins using the checkout scm pipeline step. It’s a full clone and in some cases, it’s a fast-forward merge, in other cases, a regular merge (without conflict).
What I understand is that the sonar.scm.revision property will be correct in case of fast-forward merge, not in case of a merge.
When we get rid of it, we have an other error in the SonarQube PR scan (that the commit was not found).
For now, I’ve gotten rid of the sonar.scm.revision flag to start from a clean slate ; but I would need to test both fast-forward merges and regular merges.
I believe it’s the merge that’s the problem. It creates a new commit number that doesn’t exist on the GH side. Can you try it without, and drop the sonar.scm.revision parameter?
And again, there’s no real point in passing these parameters on the analysis command line:
That’s your problem. You’re trying to decorate a commit that doesn’t exist. So you need to either not perform the merge, or perhaps try this community recommendation:
We have tried to pass sonar.scm.revision being equal to the last revision of the source branch, by taking the value of git rev-parse origin/${env.CHANGE_BRANCH} and it seems to do the trick.
