We’ve been using SQ integrated with Azure DevOps Server for quite a while now and I want to enable the quality gates to stop merges to master when analysis fails.
I have successfully enabled this on our master branch in a repo by adding the “Requires approval from additional services” value of “SonarQube/quality gate” on the master branch policy.
However, this issue is that in the ADO Project we have 4 different repos - each with their own SQ project, but if any of the 4 SQ projects fails then all quality gates fail for the master branch policy in any of the repos. I have made sure that the build each reference the correct SQ project.
Right now, if SQ projects “project1”, “project2” and “project3” pass but “project4” fails, merges for the first three projects complain that the quality gate has failed and are blocked.
Am I doing something wrong? Is there a way to limit the quality gate in ADO to just check the specific SQ project?
I would reckon that the same repo is being referenced in the project settings (Project Settings > Pull Request Decoration) – although that’s just a guess.
Would you be able to share some screenshot(s) demonstrating the issue? I’m having a hard time wrapping my head around the details (are multiple builds triggering from 1 PR? Is it really entirely separate repositories, or a monorepo?)
It is on one ADO project with 3 git repos in. One repo is old code which totally fails SQ analysis. I do not have a quality branch policy on that repo.
Two new repos have quality gates on. Attached are some screen shots to explain the issue.
You can see here the repo has 3 branches. The one I want to merge is “feature/sq-ci-test” which has passed analysis:
What I see so far is that you are successfully executing branch analysis, but not pull request analysis. The former shouldn’t result in anything being reported on your PR, while the latter will. This can happen a few ways, but the usual suspects are:
In your pipeline, you are manually configuring sonar.branch.name – this shuts off automatic configuration of the Pull Request analysis parameters
You are not running a PR build – in fact, I think this is the most likely culprit, as we we can see there’s no build policy in this screenshot