SonarCloud Pull Request integration with multiple builds

@mickaelcaro any updates??

1 Like

Any updates?

May as well put another hand up - would be nice to at least get confirmation that this is still planned to be implemented and hasn’t been dropped.

1 Like

Hi there,

Yes this is still in our radar for SonarCloud but we don’t have an ETA right now.

Thanks for your patience.

Cheers

And another set of interested users for resolving this issue!

1 Like

Eagerly waiting for this feature…

1 Like

Same here!

1 Like

Welcome @Pierre-Marie_Dhaussy to the eternal waiting game.

  • In August 2018, issue was opened and then acknowledged by @xbourguignon
  • In March 2019, @Fabrice_Bellingard stated that he estimated his team would be able to look at it in depth in 2 months.
  • In May 2019, @Fabrice_Bellingard stated that they had recruited a dedicated member of staff, solely looking at improving the Azure Devops experience and that this issue would be the “first tricky one on his list”.
  • In August 2019, @mickaelcaro stated there had been no movement on the issue.
  • In Novemeber 2019, @mickaelcaro stated that the specification of the feature was still ongoing.
  • In Feb 2020, @aurelie stated that the item is still on the radar, but there is no ETA right now.

I hope you can see that the communication from SonarSource on this is extremely wishy washy and contradictory.

I understand that it’s a difficult feature, but you either need to do it, or drop it. This will enable me to move on with my life.

If you drop it, I can move to CheckMarx (I don’t want to, but as I’ve stated before, without working Quality Gates, PRs are not blocked).

I can’t see how you don’t classify this as a bug.

Please just give us a straight answer.

1 Like

Also, wondering if this feature is planned or being worked on ?

Hello,

@gregpakes, thanx for the summary.

We are in the same boat here, we are using Azure DevOps to run a pipeline against a mono repo for each PR we trigger both a build of the .NET Core back end and an Angular frontend. We use the built in azure pipeline tasks for “Prepare”, “Complete” and “Publish”, for the .NET we are using the MSBuild option and for the angular the CLI option. Everything works fine except the publish task, which as everyone above has said only the last execution is decorated on the PR. This is a problem.

It strikes me that the implementation here should just to be able to label the publish tasks and then list them in the decoration. Appreciate things are never that easy, but you have had some time…

Hey Gordy,

The publish task is actually not what decorates the PR. The PR decoration is done by sonarqube/cloud from the server pushed back to azure devops. The publish task only sends the report from azure devops to sonarqube/cloud.

@Rouke.Broersma.IS Thanx for clarifying.

The point remains adding a label to the scan properties that can then be listened to by the ADO plug in doesn’t seem like too much of a stretch…

The ADO plugin actually does nothing with pull request decoration. It is all done from sonarqube by calling existing azure devops API’s. So no sonar scan properties are really needed.

It seems to me like if they simply change the name they use for the quality check from SonarQube/quality gate to SonarQube/{projectname} quality gate it would mostly work as is. Which should be trivial because they already have the project name. This way azure devops would not overwrite the quality gate check every time because every project would have a different name :woman_shrugging:

Okay got too bored too quickly, so have knocked together a python middleware script that listens for a webhook from sonar and then uses that to send a status to ADO. Feel free to use or not if you wish: https://github.com/izanbard/sonarhook (I know that it has no tests or logging and it could be dockerised. if you care about any of that stuff I will consider a pull request) @gregpakes

SonarHook

2 Likes

Nicely Done @gordy.

I think the fact that you are able to knock this up in hours and it solves one of the major issues (blocking PR if any build fails quality check), shows that SonarSource have put no effort into this issue at all.

Real shame.

All - it seems like a Jira issue has been created. I would encourage you to have a read of the proposed solution to see if it fits your needs.

https://jira.sonarsource.com/browse/MMF-2001

Nice that we have a Jira link now, and i agree with your consern raised there and in addition it wouldnt be ideal to merge them as different sonarcloud projects could have diffrent quality gates resulting in you want to see them individually as shown from @gordy

It is just me or does sonarsource still not realise that we do not need merged reports. They are still talking about 1 project per repo. Which IMO is not what mono-repo is about.

Agree’d, I think we are all saying we want separate reports.

As it stands, I have 2 projects that run concurrently as part of a pull request build. The first finishes, publishes (which adds comments), then the second finishes, removes all the previous comments from the first project, and adds its own. This can mean things slip through the PR

What I want is for each project to be treated separately, instead of just the last one to finish. I also want to see which project has failed its quality gate in the status (basically, what @gordy showed in his latest post)

So my script does not fix the comments issue, it only pushes a quality gate status per sonar project, so you can put rules against those statuses.

I have tidied it up a bit from my original post, added logging and a bit more config, so might be worth another pull if you cloned it. Also super happy for forks and PRs if you want to improve it (there is lots of scope).