Project Key addition for monorepo does not work

[JonathanMeer]

Describe the bug
We have our frontend and backend in the same repository, with a separate SonarQube project for each. Our pull request check pipeline analyzes and publishes the results in two separate jobs.

With version 26.1.0, each project created its own Quality Gate status check:

• sonarqube/qualitygate/project-key-fe
• sonarqube/qualitygate/project-key-be

This allowed us to require and monitor the Quality Gate checks separately for the frontend and backend.

After upgrading to version 26.5.0, both projects now publish a status check named SonarQube/quality gate. As a result, the job that publishes last overrides the status from the other job.
Consequently, we can no longer configure separate required status checks and may miss a failing Quality Gate from the job that finishes first.

We also tried the monorepo configuration, but encountered the same behavior.

To Reproduce
Steps to reproduce the behavior:

1. In Azure DevOps, create a pull request validation pipeline.
2. Configure two separate jobs, each running a SonarQube analysis for a different SonarQube project.
3. Create a pull request to trigger the pipeline.
4. Review the status checks published on the pull request.

Expected behavior
SonarQube should publish a separate Quality Gate status check for each analyzed project, with the project key included in the check name. For example:

• sonarqube/qualitygate/project-key-fe
• sonarqube/qualitygate/project-key-be

This ensures that each Quality Gate result can be tracked and enforced independently.

Screenshots
The screenshot shows the old Quality Gates with the project keys and the new quality gate without it.

Software Versions

• SonarQube Version: v26.5.0.122743
• Plugin Version: 26.5.0

[sebastiaanspeck]

The SonarQube/quality gate matches the SonarQube Developer Edition. Do you have the possibility to setup a SonarQube Developer Edition and check how the monorepo with the Quality Gate works?

[JonathanMeer]

@sebastiaanspeck Thank you for the quick response.
Unfortunately, we do not have access to a SonarQube Developer Edition instance, so we are unable to test this configuration.

[sebastiaanspeck]

sonarqube-community-branch-plugin/src/main/java/com/github/mc1arke/sonarqube/plugin/ce/pullrequest/azuredevops/AzureDevOpsPullRequestDecorator.java

Line 161 in 81c7ae1

new GitStatusContext("SonarQube", "quality gate"),

A fix might be:

     @Override
     protected void submitPipelineStatus(AzureDevopsClient client, PullRequest pullRequest, AnalysisDetails analysis, AnalysisSummary analysisSummary, ProjectAlmSettingDto projectAlmSettingDto) {
         try {
             String description = analysis.getQualityGateStatus() == QualityGate.Status.OK ? "Quality Gate passed" : "Quality Gate failed";

+            boolean isMonorepo = Boolean.TRUE.equals(projectAlmSettingDto.getMonorepo());
+            String contextName = "quality gate" + (isMonorepo ? " - " + analysis.getAnalysisProjectKey() : "");
+
             GitPullRequestStatus gitPullRequestStatus = new GitPullRequestStatus(
                     GitStatusStateMapper.toGitStatusState(analysis.getQualityGateStatus()),
                     description,
-                    new GitStatusContext("SonarQube", "quality gate"),
+                    new GitStatusContext("SonarQube", contextName),
                     analysisSummary.getDashboardUrl()
             );

This mirrors the approach used in GitlabMergeRequestDecorator.

[JonathanMeer]

@sebastiaanspeck This looks exactly like the solution we are looking for. What is the process for getting this included in an upcoming release, and when can we expect such a release?
At the moment, this issue prevents us from using SonarQube properly with our monorepositories.

[sebastiaanspeck]

I can open a PR for it, but we need @mc1arke for a release.