Scanner: Allow dryrun flag

A few questions to help you:

  • What are you trying to accomplish?
    The sonar-scanner should have a dry-run flag available which will allow the scanner to do everything that it currently does, except for publishing the analysis to the sonarqube server.

  • Why does this matter to you?
    With CICD pipelines, you sometimes need to test things without making permanent changes. The sonar-scanner process can sometimes run for a number of minutes and consume large amounts of memory which is things that need to be tested within a CICD pipeline.
    An example where you want to do this would be where you are planning or building a new CICD pipeline and need to test the execution of sonar linting, but you don’t want the results pushed as the runs are only part of testing and has no bearing on product development.
    Being able to set a dry run flag will then take the sonar-scanner through it’s usual process, but not submit the results to sonarqube.

  • How would that look in [product]? Alternatives?

  • How would we know it works well?
    The sonar-scanner process will run without submitting the results to sonarqube, and printing a message that the dry-run flag is enabled, so publishing is disabled.

  • Why should it be a priority now?
    This will help teams to test sonar-scanner in a near production environment without needing to publish analysis results but still able to get the performance impact of sonarscanner within the cicd pipeline.


I’d like to vouch for this as well. In our automation it would be very helpfull to run a analysis and see if the quality gate would be triggered without actually submitting the results.

Hi @maaheeb,

Welcome to the community!

Can you please tell me more about your need? Why do you want to run the scanner and spend time analyzing the code but not understand the quality of your code?

For a “test” use case, I would suggest running the pipelines on a test instance.


Hi @Chris ,
as a CI engineer I want to ensure that changes to the build environment setup does not affect the execution of the sonar-scanner, but I am not interested in the findings of the scanner.

Let’s assume that I have a PR that changes only the CI build configuration (zuul/jenkins/…) and this change must be verified with the actual target build, but also with all other test jobs in the pipeline (e.g. sonar-scanner/unit test execution) in order that the change does not affect/break the builds.

In this case, it would be handy to pass the dry-run flag to the sonar-scanner.

Thanks for the explanation, Pieter.
In that case, don’t you want to check that the change doesn’t affect the results of the analysis? A change in the build configuration may have an impact on the files that are analyzed and on the issues that can be found.

Hi @Chris,
ideally yes, that would be helpful, but we have a complex setup. We are using ZUUL as our CI tool.

For better understanding, we have two repositories and one CI job:

  1. zuul → contains job definition and configurations

  2. source → contains the source code to be tested

  3. One generic CI job that executes the sonar-scanner and can be added to multiple source repositories.

So, the job definition and configuration is in a separate repository and the to be analyzed source files are not part of the configuration repo. When you create a PR in the zuul repository, a CI job will spawn that executes the sonar-scanner on the source files within the source repository. This is done in order to check if the job will be successful when it runs in the source repository.

As far as I understand it, there is no possibility to upload the results to the source repository, but annotate the results in the zuul repository, where I need the information. In this case, I only want to check if the sonar-scanner is still executable in the CI environment and the zuul change will not break the jobs in the source repository.

Best regards

Thanks. I think I got it. Correct me if I’m wrong but, in other words, you want to check that the changes you apply to a common pipeline definition won’t break SonarQube analyses, without triggering all project analyses.
We don’t have any plans to address this on our current roadmap, but we’ll keep a record of this and continue to look out for similar requests.

1 Like