SonarQube ProjectKey changes evenafter hardcoding part of PrepareSonarQube task

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension) SonarQube Developer Edition
  • what are you trying to achieve Code analysis
  • what have you tried so far to achieve this Integrated with Azure Devops pipeline, created a project in Sonarqube and use the project key in Maven Build, but the project key changes to different name while running the maven task, so we don’t get the report on sonarqube because of mis matching project key

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

Hey there.

Can you share your Azure DevOps Pipeline YML that show how you’re setting the project key?

You should also make sure the project key isn’t being set anywhere else, such as in the pom.xml of your project or as a command line parameter (mvn sonar:sonar -Dsonar.projectKey=myProjectKey)

Hello Colin,

Thanks for your response. Please find my yaml.

  • task: SonarQubePrepare@5
    SonarQube: ‘SQ’
    scannerMode: ‘Other’
    extraProperties: |

    Additional properties that will be passed to the scanner,

    # Put one key=value per line, example:
    # sonar.exclusions=**/*.bin

But it translates to groupId:artifactId,

But evenafter the successful completion of analysis, SOnarQube project says No The main branch has no lines of code.
I double checked the branch name matches with Azure devops branch name.

Disable the SCM Sensor, fixed this issue, I can see reports are updated in Sonarqube.

Question: I have another project where SCM sensor is enabled, still working fine, what would be the impact of disabling the SCM sensor?

Hey there.

I’m surprised to hear that disabling the SCM sensor had an effect on the project key – it shouldn’t have.

Something I noticed when you posted your Azure Pipelines YML is that sonar.projectKey isn’t indented quite in line with the other (commented out) properties. It may be affecting the interpretation of sonar.projectKey. If you indent it one more space (and stop disabling the SCM sensor), is there any effect?

Disabling the SCM sensor will prevent files from being blamed, issues being assigned to the correct author, new lines being detected, etc…

Hello Colin, Disabling SCM sensor doesn’t change the Projectkey. But it started analyzing my Code and started reporting to soanrqube.

with SCM sensor, its indexing 0 files and no line of codes to scan.

Enclosed the logs. (36.2 KB)

Hey there.

I can’t find anything in the logs you shared about 0 files indexed – am I missing something, or maybe there are other logs to share?

Oh its my fault, my SCM sensor is disabled already. Could you please check the enclosed log now, we have the SCM sensor turned on and its indexing 0
Scan_log.txt (32.1 KB)


It looks like files are being ignored because of SCM-based exclusions:

2023-01-31T02:54:56.3320126Z [INFO] 7 files ignored because of scm ignore settings

You can keep SCM enabled put turn off SCM based exclusions by adjusting sonar.scm.exclusions.disabled (see the documentation on analysis parameters).

It look likes you do some copying around of your files before you run the build / SonarQube analysis, and also exclude the .git folder when you do this. This probably explains the behavior.

Why do you copy your code into a new folder before running the build / analysis?

Thanks for your clarification. I added the sonar.scm.exclusions.disabled parameter and tunred on the SCM sensor, Now all files are indexing properly and report back to SonarQube. But we see below warnings. Enclosed the Log

## Warnings

Missing blame information for 7 files. This may lead to some features not working correctly. Please check the analysis logs and refer to the documentation.

Part of project requirement we are copying the application module code inside the parent code to execute the build, otherwise it will fail.
Scan_log_NEW.txt (36.8 KB)

It makes sense this happens because you are specifically excluding the .git folder when you perform the copy. This is required information to blame the files. You should find a way to preserve this folder, or run the analysis when the folder is still there.

Noted with thanks.