We have a scenario where a single VSTS Pull Request can trigger multiple builds. The issue is that SonarCloud only creates a single code quality status against the PR which seems to only link to one of the builds.
Is it supported to have multiple builds and use the pull request integration? If so, should there not be 2 status gates?
When you click the link, it takes you to one of the builds in SonarCloud and not the other.
Apologies, I don’t think I was clear. I don’t have multiple analysis in a single build definition. I always have a single analysis per definition. But a pull request can trigger multiple builds. This is a standard feature. This is why VSTS supports Path Filters.
Yes that’s exactly right. The main issue is that there is only one Status Gate on the PR whereas there should be 2. In our scenario, we have this Status Gate as a requirement for PR completion. So as there is one one gate, the second build gets ignored completely, allowing the PR to be completed without the SonarCloud issues fixed.
Hi Xavier,
Sorry to resurrect this thread after a month, but I was wondering what the outcome of asking the dev team was - we have the same issue with our PR status gate.
Thanks, Sean.
our dev team acknowledged that the PR decoration was not working well in such situation, and there is now a ticket in the backlog. I just can’t give you an ETA for it.
Do you know any news in reference to multiple SonarQube analysis per project on one pull-request ?
I already purchased the SonarQube license to have the possibility of Pull Request analysis and for PR when changes are from two different projects eg. angular and .NET I only see comments and status from one of them.
+1 We have this exact issue on VSTS/DevOps. Or build builds both Angular & .NEt Projects and runs an analysis against each one. The one which finishes last always overwrites the status and comments fromn the other analysis.
We literally just got our license yesterday and this is a showstopper for us
Has anyone got any workarounds?
Hi all, just to give you heads up on this: we were not able to progress on that topic just yet. This is not forgotten - just not on the top of the list of the current priorities.
This issue really hampers the usefulness of SonarQube.
The main purpose for me is to stop a codebase getting worse. This is acheived by blocking PRs based on a quality gate. This bug renders the blocking a PR based on quality gate useless.
The blocked status of the PR is dependent on a random triggered build.
There could be 4 builds, one of which is fine and the other 3 introduce major issues and have a failed quality gate. Yet the PR can be merged with no issues.
I would like to also voice our support of this feature. Having only a single Quality Gate and PR decoration is unworkable for us. We have had to split our builds out to only build the code that has been changed in a Pull Request, otherwise all of our build agents get utilized, and we end up with a huge queue that doesn’t clear until after everyone’s gone home.
VSTS supports and encourages this practice. It only makes sense that SonarCloud works with this model as well.
This, for us, is a huge deal, which we believe needs to be addressed as a higher priority.
+1.
Same situation for us, at the moment this is a complete deal breaker.
We also use the split build approach but its starting to get a point where it’s cumbersome to maintain since the projects and builds keep increasing.
I understand that there might be more concerning issues on the backlog but it would be great if we could have a fix for this as soon as possible.