SonarCloud Pull Request integration with multiple builds

vsts
pull-request

(Greg Pakes) #1

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.


GitHub pull request decorations for monorepos
Questions on pull request analysis
Concurrent analysis of projects with PR decoration
(Xavier Bourguignon) #2

Hi Greg,

How do you configure VSTS to trigger multiple builds with a single PR ?


(Greg Pakes) #3

Its a fairly standard configuration. If you have multiple solutions in a single git repo, you setup CI builds with path filters.

Then in your PR config you setup build validation using the same path filters.


(Xavier Bourguignon) #4

ok, if you trigger multiple analysis in the same build definition, you will have only one link to SonarCloud quality status.

A good practice is to have one build definition with only one analysis per solution in your single git repo.


(Greg Pakes) #5

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.


(Xavier Bourguignon) #6

Understood.

And in the Pull Request page, there is only one Status

Whereas there’s a specific SonarCloud report per build


(Greg Pakes) #7

Hi,

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.

thanks,

Greg


(Xavier Bourguignon) #8

I confirm that the link on the PR will be the quality status of the last triggered analysis.

I see with the dev team if we can improve this.


(Greg Pakes) #9

Thanks so much! Much appreciated


(Sean Fleming) #10

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.


(Greg Pakes) #11

Any news on this?


(Fabrice Bellingard) #12

Hi Greg,

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.


(Rafal Kasa) #13

Hi

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.

A similar issue was fixed for Jenkins please look at this PR:
https://github.com/SonarSource/sonar-github/pull/31

Thank you in advance to add such feature into SonarQube Extension for VSTS


(Ian Bennett) #16

+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 :frowning:
Has anyone got any workarounds?


(Greg Pakes) #17

Hi @Ian_Bennett

I’m pretty sure there aren’t any workarounds at present besides a full re-structure of your repository.

We are at the dev teams mercy.

thanks,

Greg


(Dana) #18

Hi All,

Any news on fixing this issue or if it’s in process of being fixed by the devs? Our team is experiencing this issue as well.

Thanks,
Dana


(Fabrice Bellingard) #19

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. :confused:


(Greg Pakes) #21

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.

This is a big issue and needs a higher priority.


(Stephen Larkin) #22

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.


(João Gonçalves) #23

+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.