SonarQube Quality gate on new code. Fails on first attempt. Succeeds on second attempt

SonarQube Server / Community Build
, ,
1

Must-share information (formatted with Markdown):

  • SonarQube Server v2025.4.2 (112048)
  • deployed as zip
  • expected consistent quality gate result

Our quality gate is for New-Code only.

Our project has multiple branches.

We have defined the new code as follows:

  1. develop, our main branch as the reference branch
  2. For develop, our main branch, we have selected Previous version as the baseline

What are we facing?

  1. During the first run, the quality gate fails.
  2. During the re-run of the same code, the quality gate is passed.

Edit 1:
Command to scan:
docker run --rm -t --name “Name” -v “CodePath” sonarsource/sonar-scanner-cli -Dsonar.host.url=“https://URL/” -Dsonar.projectKey=${bamboo.sonar.Key} -Dsonar.token=“${bamboo.sonar.ent.secret.token}” -Dsonar.projectVersion=${bamboo.version.assemblyVersion} -Dsonar.coverage.exclusions=“${bamboo.sonar.Exclusions}” -Dsonar.branch.name=${bamboo.planRepository.1.branchName} -Dsonar.qualitygate.wait=true -Dsonar.exclusions=“${bamboo.sonar.Exclusions}”

3

Hi,

Welcome to the community!

This means that every time the sonar.projectVersion string changes, you’re resetting what’s considered new.

At a guess, the assemblyVersion is different with each build? That would reset the new code with each analysis and explain what you’re seeing.

 
HTH,
Ann

4

Sorry, but when we are re-running that step, nothing changes.
I removed the projectVersion and still facing the issue.

5

Hi,

To be clear, when you re-run the step, exactly the same bamboo.version.assemblyVersion is used?

By removing that analysis property, you defaulted it, I believe to “Not provided”, thus resetting the “new code” once again.

What happens when you run it the second time with no sonar.projectVersion (i.e. the default) value?

 
Ann

6

The assembly version remains the same. The assembly version is set during build and remains constant.

After removing projectVersion, I had the same scenario for a new branch.

7

Hi,

To be clear, you ran two successive analyses with no sonar.projectVersion (so, the default value), and you saw issues that were “new” for the first analysis get moved out of “new” for the second one?

Could I have a screenshot of the left column of your Activity tab, redacted as necessary?

 
Thx,
Ann

8

Hi,

Yes, you are getting it right.

Please fidn the snapshots below:

image
image1087×693 41.3 KB

image
image431×403 21.3 KB

9

Hi,

Thanks for the screenshots. They’re very helpful, particularly the one I didn’t ask for (:sweat_smile:) that shows a QG change with no issue change (and no version change).

I had assumed that something would jump out at me from your screenshot, but nothing does.

Do you still have access to the analysis logs from those last two runs? Could you post them here, redacted as necessary?

The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.

This guide will help you find them.

 
Thx,
Ann

10

Hi Ann,

Sorry for the delay.

We had the same experience. See the attached screenshot and the log files

image
image683×315 15.1 KB

Log_Failure.txt (94.0 KB)
Log_Success.txt (93.9 KB)

Hope this helps.

11

Hi,

This stands out to me in both logs:

SCM provider autodetection failed. Please use "sonar.scm.provider" to define SCM of your project, or disable the SCM Sensor in the project settings.

These prerequisites are listed for PR analysis, but they’re generally applicable. Can you make sure they’re in place? In particular, I think we need to hit this point first:

The CI/CD host’s local repository contains valid repository metadata (e.g. the .git folders have not been removed).

 
Thx,
Ann