On this page
SonarCloud can automatically analyze your code simply by reading it from your repository, without the need to configure a CI-based analysis.
When you first import a project that is compatible with automatic analysis, the first analysis behaves differently from subsequent analyses. On the first analysis not only will the main branch be analyzed, but, also the most recently active pull requests, up to a maximum of five. After that, automatic analysis will trigger a new analysis on each push to the default branch and on each push to any pull request branch.
Currently, automatic analysis has the following limitations:
- It is only available for GitHub repositories.
- Branch analysis (analysis of non-pull request branches other than the main branch) is not supported.
- Multiple projects bound to a single repository (the monorepo strategy) are not supported.
- T-SQL and PL/SQL cannot be analyzed automatically because they share the same file extension, so this requires manual configuration in the CI-based mode.
- Code coverage information is not supported.
- Import of external rule engine reports is not supported.
Analyzing Gradle files
If you are analyzing Gradle files, your Gradle build file must be located in the root of your repository in order to be detected by the scanner. If your Gradle build file is located in sub-directory, you have to use CI-based analysis instead.
For more information, see Analyzing multi-project builds.
Automatic analysis is available for most of the languages that SonarCloud supports with the following exceptions:
Not yet supported
Automatic analysis now also supports Azure Resource Manager and its two formats, JSON and Bicep.
For new projects:
- After importing a project from GitHub, SonarCloud will automatically check whether your project is eligible for automatic analysis. This should take a few seconds.
- SonarCloud will deem a project eligible for automatic analysis only if fewer than 20% of the lines of code in the project are in a non-compatible language.
- For a Java project to be eligible, the amount of Java code cannot exceed 10MB.
- SonarCloud will reject a project for automatic analysis if it contains a
sonar-project.propertiesfile (see Presence of a properties file).
- If your project is eligible, SonarCloud will automatically trigger the first analysis. On this first analysis, the system will analyze the main branch of the project and the five most recently active pull requests. All you have to do is wait for the analysis to finish.
- If your project is not compatible, SonarCloud will suggest other analysis methods such as using a CI tool.
- You can force automatic analysis on an initially non-eligible project. However, doing this is not recommended as it will typically not provide useful information. To force automatic analysis, do one of the following:
- From your project’s homepage, click the Force Automatic Analysis button.
- From your project’s Administration > Analysis Method page, turn on Automatic Analysis.
For existing projects:
- Go to your project’s Administration > Analysis Method page and turn on Automatic Analysis.
- The Analysis Method page will display a compatibility check, so you are aware of our recommendations for your specific project.
If you import a project that already contains a
sonar-project.properties file, SonarCloud will deem the project ineligible for automatic analysis. You can still force automatic analysis if you choose. The reason for this limitation is that the presence of a
sonar-project.properties in a newly imported project usually means that the customer is migrating from SonarQube and probably wishes to continue with the same CI-based configuration as they were using on that platform, particularly since automatic analysis does not offer all of the same features as CI-based analysis.
If a project uses automatic analysis, then in the Project Overview > Information under Last analysis method the system will display Analyzed by SonarCloud:
Automatic analysis is not intended to be used in conjunction with CI-based analysis.
If you do enable automatic analysis, you must ensure that you do not have any CI-based analyses configured. If you do then these CI-based analyses will fail and cause a failure in your build process.
Similarly, if you wish to use a CI-based analysis on a project, you must ensure that automatic analysis is disabled for that project.
This is done to prevent duplicate analyses from being sent to SonarCloud that would cause problems in your project activity reports.
Go to your project’s Administration > Analysis Method page and turn automatic analysis Off.
From the same page, you can then follow one of our tutorials for configuring SonarCloud analyses with another method.
You can add more configuration to your analyses by adding a
.sonarcloud.properties file to your repository’s default branch. Note that this is different from the
sonar-project.properties file used for CI-based analysis.
Here are the supported optional settings for the
Note that some of these settings can also be configured from the SonarCloud UI. In your project’s Administration > General Settings > Analysis Scope > Files, you can define file exclusions and inclusions. If you have different options set on the UI and the
.sonarcloud.properties file, SonarCloud will only take into account the one from the
- This feature works for any project, public or private.
- It can be activated at no extra cost.
- If you were previously using the Automatic Analysis Beta, removing the
.sonarcloud.propertiesfile will no longer disable automatic analysis. It will only disable the additional configuration settings you might have defined in it. You will still have to disable automatic analysis from the SonarCloud UI, in the Administration > Analysis Method page.
Automatic analysis provides the quickest way to get your Java project up and running on SonarCloud and see code analysis results fast.
However, in the case of Java, automatic analysis does currently have some limitations:
- To be eligible for automatic analysis, your Java project must use either Maven or Gradle and the total amount of code in the project must be less than 10MB.
- Security vulnerability rules are not yet supported with the following exceptions:
- Maven - cross-site scripting is not yet supported but is available using ci-based analysis.
- Gradle - security vulnerability detection is not yet supported but is available using ci-based analysis.
- Rules that belong to this list are not supported because the results that they currently produce are not sufficient for automatic analysis.
- Not all properties are supported (see below).
Java automatic analysis does not support the following properties:
This is because we assume that your files will follow the standard directory layout that is expected by Maven and Gradle (
**/src/test/**/*) for Java projects.
SonarCloud automatic analysis now also supports .NET projects. .NET Core and .NET 5 and .NET 6 projects can be analyzed but are subject to some limitations:
- Projects must contain at least 80% code in languages compatible with .NET. The amount of .NET code for automatic analysis is calculated by adding the sum of *.cs and *.vb files together.
- All security vulnerability rules are supported, except cross-site scripting which is not available yet. XSS detection is available using ci-based analysis.
- Projects must contain at least one XML file - *.csproj or *.vbproj. A combination of both file types is acceptable.
- The csproj/vbproj files must have “Project” as the root element, and “Sdk” as the project attribute. For example, <
- Projects must not contain *.shproj file extensions.
With these limitations in mind, the next step in your Java or .NET project onboarding is to set up CI-based analysis to get the most out SonarCloud analysis. You can find more information on that here. In the meantime, the capabilities of automatic analysis will continue to evolve and improve.
- C & C++ automatic analysis does not have any toolchain or project structural requirements.
- C & C++ can be analyzed in combination with all other supported languages (including Java and .NET.)
SonarCloud automatic analysis for C and C++ is already available and ready to analyze. The quality of analysis is very similar to a CI-based analysis and, for most users, it is the only analysis you really need.
For other users, there are a few cases where a CI-based analysis remains a better option.
- If your project is so big that the analysis cannot be completed before the analysis times out, automatic analysis will fail.
- If you require faster analysis. You should run the analysis using self-hosted resources with an increased hardware capacity. It would also allow you to keep full control of the analysis cache if needed.
- If your project uses generated code that you want to analyze. For example, this can happen in some custom build systems.
- If you need control over the configuration of your code. For example, with automatic analysis, you cannot choose your code’s target platform/architecture. Automatic analysis uses a configuration that maximizes the amount of code analyzed and the OS and architecture used for this can differ from your own configuration.
- If your project is experiencing missing issues. In rare cases, automatic analysis can lead to such limitations.