We’ve got some exciting news for teams bringing new projects into SonarQube Cloud: starting today, we’re rolling out Scanner CLI automatic configuration in open beta for Python, JavaScript/TypeScript, and Maven projects.
What is it?
When you use the Scanner CLI, SonarQube Cloud now automatically detects your repository and available build-system information, then applies the analysis settings needed for an accurate analysis - no language-specific scanner selection or analysis parameters needed for supported projects.
Languages and ecosystems currently automatically configured:
-
Python projects (from pyproject.toml files)
-
JavaScript and TypeScript projects (from package.json files)
-
Maven projects
We are working hard to bring this feature to the rest of languages supported in SonarQube.
Who is this for?
-
Individual developers who want to add Sonar analysis to a new project’s CI quickly
-
Development teams setting up new repositories who’d rather skip choosing and configuring dedicated, language-specific scanners
-
DevOps and platform teams managing shared CI templates who want to cut configuration overhead across many projects
How does it work?
Scanner CLI automatic configuration can be opted into at either the project level or per analysis run by setting sonar.scanner.autoconfig.enabled=true.
Automatic configuration evaluates the entire repository and uses build-system metadata to optimize analysis setup, instead of restricting focus solely to build-managed files. This produces precise configurations for the vast majority of projects, while custom adjustments can still be applied to suit specific repository needs.
For more on how it works, fine-tuning, and troubleshooting, see Scanner CLI automatic configuration.
How does automatic configuration compare to dedicated scanners?
Scanner CLI automatic configuration is designed to match the analysis precision of the SonarScanner for Python, the SonarScanner for npm, and the SonarScanner for Maven. It feeds the analyzers the same configuration those scanners would, such as the Python version, test classification, and the Java classpath and bytecode. For Maven projects, this assumes the project is built before the analysis runs in the same CI job.
Dedicated scanners remain the better fit for teams that want the analysis inside their ecosystem’s own tooling. They install through pip, npm or Maven, keep their settings in the project’s build files, and run as part of the build.
What happens with existing projects?
Existing projects can retain their current Scanner CLI configuration - no migration is required. We advise keeping Scanner automatic configuration turned off for projects that already have a set configuration, as turning it on could modify source and test classifications, detected exclusions, or the overall analysis scope.
Help us improve it
Scanner CLI automatic configuration is in open beta, and we’d love your feedback based on your own projects - what worked well, what needed fine-tuning, and anything that surprised you.
If the detected configuration doesn’t match your repository, you can re-run with verbose logs (-Dsonar.verbose=true) and pull out just the detection block:
sed -n -E '/INFO Detecting build system information/,/INFO Build system information detected in/p' <your-scanner-log>.log
That shows exactly what build system and settings were picked up - the fastest way to spot a mismatch before reaching out.
If you’d rather go straight to Support, include those Scanner CLI logs and a short description of your repository structure (with secrets and credentials removed).
Would you be open to a brief customer interview to share your experience?
P.S. Do you have feedback or questions about your experience? Book a call with me (a Product Manager) or DM me.