SonarCloud Pull Request integration with multiple builds

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:

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.

3 Likes

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.

3 Likes

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

2 Likes

+1 This is a huge pain for us, as well. We can work around the issue by triggering the Pull Request Builds manually, one at a time, but this really defeats the ease of use and we are dependent on developers following this process to prevent new issues getting into our codebase

1 Like

+1 Throwing my hat in the ring here. I very much want this feature as well.

@Fabrice_Bellingard I don’t see anything on your product roadmap for this functionality. I wonder if you could give us a better sense of the timeline? Is this something you’d like to get does this quarter? This year? Next year? Not scheduled? Is it in the bottom of the pile or in the middle or unprioritized?

I understand these are difficult questions. If the honest answer is “don’t know” I can accept that but I will want to find my own work-arounds.

Thanks!

Hi Alex, Bill, Joao, Stephen and Greg,

Situation has not changed since my last post 3 weeks ago:

Be sure that on my side, this issue is definitely in my radar. As you pointed out @Alex_Denton, this is quite tricky, especially given the the way scanners and analyses are currently designed. There is no obvious and quick solution which comes to mind, and this needs to be investigated in depth with team mates who know the Microsoft world very well (and they’re very busy those days…).

If I had to give an estimated timeframe when I feel we’ll be able to investigate this in depth, I’d say in about 2 months from now.

I appreciate that. It definitely helps with planning on my side. I’ll be greatly looking forward to this feature.

Thanks to and your team for your hard work!

1 Like

+1 would be very welcome feature.

We have the exact same issue here but with github:

So this issue is closed as duplicate, that’s why I come here to ask for this feature too.

Would be useful to be able to have distincts sonar PR decoration for each sonar analysis triggered by the build:
If I modified several modules in the same PR, then I will triggered distinct sonar analysis and I would like to have distinct PR decoration for each modified modules.

2 Likes

Hi @Fabrice_Bellingard, I’m sure I’m not the only one who has been waiting with bated breath to see how this was progressing. I was wondering if it was possible to get an update on the timeline for this feature?

You’re not the only one… :frowning:

1 Like

8 Months and counting…

1 Like

We’ve recently onboarded a new member in our crew who is going to dedicate all his energy on the Azure DevOps user experience, and as soon as he’s up-to-speed, this topic is going to be the first tricky one on his list! (no pressure @mickaelcaro :wink: )

3 Likes

Also facing the same issue here.

We have a repo with multiple projects that are scanned differently.

I have configured a Jenkins job with multiple sonar scanners, however if an issue is found with the 1st project, the status is overwritten by the 2nd, 3rd and 4th scan.

A simple fix would be to give us the ability to assign the Status context name, e.g. sonar.pullrequest.statusname=Sonarqube-1

Could we please have an update regarding this issue?

@DanS Can you detail what type of project your are analyzing in this repository, using which scanner, please?

We have the exact same requirement. Monorepo but only one status gate shows in PR checks on Github. Where is this issue at?

2 Likes

we have a mono repo with several module inside: 1 java api, 1 front js, 1 front js, 1 batch, etc.

when we create a pull request we need to exec several sonar analysis: 1 java, 2 js, 1 other etc.

but only the latest analysis will be used by github pull request apps to display results.

we would like to have all results in differents checks as we can have with circleci builds steps for instance.

Hey @Fabrice_Bellingard and @mickaelcaro any chance of another update on where we are with this?

1 Like