SonarQube issue: Previously accepted legacy issues are failing Quality Gate after merging develop

SonarQube Cloud
, ,
1

Previously accepted issues no longer recognized after merging develop into feature branch

CI system used

Gitlab CI

Scanner command used

[ '/<project-path>/sonar-binaries/sonar-scanner/bin/sonar-scanner', '-Dsonar.host.url=https://sonarcloud.io', '-Dsonar.token=[MASKED]', '-Dsonar.cfamily.compile-commands=/<project-path>/sonar-ci-artifacts/<artifact-id>/compile_commands.json', '-Dsonar.qualitygate.wait=true', '-Dsonar.qualitygate.timeout=600' ]

Languages of the repository

C

SonarQube/SonarCloud project URL (if public)

Not public

Error observed

I’m trying to understand an unexpected behavior we experienced during our CI pipeline.

Our project contains a number of legacy SonarQube issues. Normally, when we modify a source file, SonarQube re-analyzes the file and those existing issues are detected again, causing the Quality Gate to fail.

Our usual workflow is to mark those legacy issues as Accepted and rerun the pipeline. After the rerun, the Quality Gate passes because those issues are no longer considered blocking.

Today I encountered a different behavior.

I had to merge develop into my feature branch to resolve merge conflicts before opening the final merge into develop. After performing this merge, the next SonarQube analysis reported a large number of legacy issues.

I marked the issues as Accepted, reran the pipeline, but they continued to fail the Quality Gate. I repeated this process several times, also trying to set the issues as False positives with the same result.

I would like to understand whether this is expected behavior.

Specifically:

  • Can merging develop into a feature branch cause SonarQube to lose issue tracking and treat existing issues as new ones?

  • Is there a difference in how Accepted and False Positive are handled by the Quality Gate?

  • Has there been any recent change to issue tracking or Quality Gate behavior that could explain this?

Error logs

Quality gate fails

Steps to reproduce

  1. Start from a feature branch.

  2. Merge develop into the feature branch to resolve merge conflicts.

  3. Run the SonarQube analysis.

  4. Observe that multiple legacy issues are reported.

  5. Mark the issues as Accepted or False positives.

  6. Rerun the pipeline.

  7. Observe that the Quality Gate still fails because of the same issues.

Potential workaround

I don’t know how to solve this, had to temporary disable the scanner pipeline stage .

2

After looking into this further, I found the root cause.

On this project we have multiple build configurations. Each configuration builds the project differently, resulting in different generated code and, consequently, different analysis results.

In the pipeline, both configurations are first built using the SonarQube Build Wrapper. During the scan stage, the SonarQube scanner is automatically executed once for each build that was previously wrapped.

I recently modified a source file that already contained several legacy issues. Since I touched the file, those existing issues were reported as new, causing the Quality Gate to fail for Build Configuration 1.

I marked those issues as false positives (or accepted them as legacy issues) and reran the pipeline. This time, the scan failed for Build Configuration 2. Although the underlying code is the same, the different build configuration produces different code layouts, so the issues are reported at different locations and are treated as different issues by SonarQube.

After accepting the issues for Build Configuration 2, the next pipeline run fails again for Build Configuration 1. This happens because each scan overwrites the previous analysis of the same SonarCloud project, and the issue tracking is configuration-specific. As a result, the two configurations continually invalidate each other’s accepted issues, creating an endless loop.
What is the best way to deal with such situations?

3

Hi @Mattia_Van_der_Meer,

Good diagnostic work. Your root cause identification is correct. The key mechanism is that SonarQube matches issues across analyses using content hashes on the lines where issues are found. When Build Config 2 produces different compilation units or generates different files than Config 1, the issues it raises don’t hash-match the previously-accepted ones from Config 1, so they appear as new issues rather than being recognized as the same accepted findings.

We do have on our roadmap to bring support for sonar.cfamily.variants feature which would address exactly the scenario you’ve described. It’s currently only available on SonarQube Server but it’s planned to bring it to SonarQube cloud, no timeline to share yet.

In the meantime, the simplest path forward is to create separate SonarQube Cloud projects per build configuration, using a distinct sonar.projectKey for each. Each project then has its own independent issue tracking and quality gate, which breaks the invalidation loop entirely. The tradeoff is that you lose the single consolidated view, but issue stability is preserved.

Does that help?

Best regards,

Stevan

4

Thank you for your reply and for the additional information.

For this project, we have decided to scan only the primary build configuration. However, for other projects we may need to use separate project keys for different build configurations.

Support for build variants would be a valuable feature for our use case. As an embedded products company, most of our projects support multiple hardware configurations. Requiring a separate SonarCloud project for each configuration can lead to significant code duplication, increased maintenance overhead, and additional lines of code being counted across SonarCloud projects.

We would definitely appreciate support for this functionality in the future.

Best regards,
Mattia