@jlawless - Further to your comment, I just want to add that the second build will also overwrite the Quality Gate Status.
So if your first build fails the quality gate (thus blocking the PR) and the second build does not, the second build will clear the failed Quality Gate allowing the PR to go through.
This is the biggest issue IMO and this is what @gordy’s solution solves.
Anything here? We just combined 14 repos into one large monorepo. Analysis is a major pain point for us.
@gordy - we’re in the Bamboo + Bitbucket world. I’m going to try and adapt your solution for us.
This just bit us. PR containing validation builds for three different projects from a monorepo and only the last one to run counts. Kinda defeats the purpose of paying extra for Developer edition since we only did that for the PR protection it provides. Seems like an easy fix, just add the SQ project name to the PR comment and PR decoration ADO API calls which would make comments and decoration unique to each build.
Special thanks to @gregpakes for sticking with this issue for going on two years!
Yep.
PR protection is the most important piece here. Something which @gordy has managed to provide with very little effort. Baffles me how SonarSource aren’t able to put this feature in going on 2 years now.
Hi guys,
I just noticed they created a new MMF https://jira.sonarsource.com/browse/MMF-2036 for our use case, and the description this time seems spot on!
Hello there,
As @Rouke.Broersma.IS mentionned, we’ve listened to your feedback and have drafted a new MMF that hopefully will best suit your need 
Link is this one https://jira.sonarsource.com/browse/MMF-2036 which is the EPIC link, and we also split this into each ALM that we currently support, and will begin indeed by Azure DevOps very soon.
Mickaël
Hello there,
We are very happy to announce that we added support for mono repositories on Azure DevOps.
From now on you will be able to:
Please take a look at the guide on our documentation for more details on how to set it up.
Feedbacks are more than welcome
This is great news!
One issue I’m not sure if it’s related, but our Quality Gate policies on the PRs are set as “Optional” despite the policy requirement being set as “Required”.
Is this something that you are overriding somehow?
Hi @brett.postin,
As far as I know, we don’t override any setting.
Also, I am not sure I correctly understand the issue you describe. If you need any help regarding this, please open a new ticket and I’ll be glad to help you
Cheers,
Christophe
Has this change increased the amount of required disk space on the build agent?
We are suddenly getting disk space issues and we use Azure Devops Hosted agents, so don’t have any control over the available space.
The issue is our “Require approval from additional services” branch policy for SonarCloud within Azure DevOps is set to “Required” i.e. a status of succeeded is required to complete PRs.
However the policy in the actual PR is listed under the “Optional” policies, meaning a failed SonarCloud quality gate would NOT block the PR.
If you aren’t overriding the Policy Requirements in some way (either intentionally or unintentionally) then I will raise the issue directly with Azure.
Hi @Brett,
We don’t override the required/optional option on those status.
The behavior you describe is most likely from a PR that already exists when you turned on a project as Monorepo, which was part of that PR. If it had already a Quality Gate status, when the “new” (with the project name on it) status appeared on a new analysis on that PR, the “old” one has been moved to Optional. Is that the case ? If yes, this is a known limitation, as we don’t delete existing Statuses, but only create / update ones.
HTH,
Mickaël
Hi @gregpakes
I don’t think so. The PR decoration is done only from SonarCloud to Azure DevOps, the extension has no effect on that and is not used for that specific matter (it runs analyses only).
Mickaël
It wasn’t the case no, the “new” status policies (with the project name) were being posted as “Optional”.
Following your suggestions and re-reading the documentation I think we have resolved it. We needed to explicitly setup a new status policy for each of the projects within the monorepo. After doing that and marking them as required they are now “Required” on PRs.
Just out of interest, with no explicit status policy defined, PRs are still decorated with a “new” status as “Optional”. Is that expected behaviour?
Great to read !
I couldn’t find any doc about this required/optional state in the API, so i guess that’s the default value and the expected behavior yes. .
We will add a note on our documentation about that.
Thanks !
This is expected behavior from the azure devops side at least, yes.
Hello all,
We released the support for monorepos on GitHub today. Please check out the announcement post for more information. Feedback is always welcome!
Cheers,
Martin
Hi all!
If, like me, you have been waiting/campaigning for this feature since 2018 good news! This feature will be released soon with sonarqube 8.7!
Enterprise Edition only… 