Setting up Clean as You Code
As a project administrator, you set up Clean as You Code in two steps in SonarQube Community Build:
- You set the quality standard for your project.
- You set a new code definition.
Setting your quality standard
We recommend using the default Sonar way quality profile and quality gate. For details and configuration options, see the Quality profiles and Quality gates pages.
Setting a new code definition
This section describes how to set up a new code definition for your project. To learn about new code, see About new code.
For each project you create in SonarQube Community Build, you need to choose a new code definition.
Configuration levels
You can define new code at the global or project level:

- Global level: Set a global new code definition at Administration > Configuration > General Settings > New Code. What you define as new code at the global level will be the default for your projects.
- Project level: Set a new code definition for your project at Project Settings > New Code.
Project new code definitions can be reset to use the default setting (only if the default setting is configured to follow the Clean as You Code methodology).
Option-specific details
Previous version
Recommended for projects with regular versions or releases. Defines new code as any code that has changed since the most recent version increment of the project.
Available at the global and project levels.
The current version of a project is determined in different ways depending on the build system:
- If the analysis is done using the SonarScanner for Maven, then SonarQube Community Build reads the version from the
pom.xml
file. - If the analysis is done with the SonarScanner for Gradle then SonarQube Community Build reads the version from the
build.gradle
file. - In all other cases, the version must be explicitly specified by setting the analysis parameter
sonar.projectVersion
.
Number of days
Recommended for projects following continuous delivery. Available at the global and project levels. Defines new code as any code that has changed in the last X days.
For example, setting the Number of days to 30 creates a new code period beginning 30 days before the current date. If no action is taken on a new code issue after 30 days, this issue becomes part of the overall code.
The default value is 30 days, 7 or 14 days are other common values. The maximum possible value is 90 days.
Specific analysis
Available at the project level. Defines new code as any changes made since that specific analysis.
To comply with the Clean as You Code methodology, this option cannot be set in the UI, as it would require frequent user action to keep it up to date. It can only be set via the Web API using the api/new_code_periods
endpoint, with analysis uuid
, project
and branch
keys as parameters.
Recommendations
- To avoid reference errors when cloning a repository, we recommend cloning all its branches.
- We recommend completing your merges using the fast-forward option without a merge commit; examples include GitHub’s squash and merge or rebase and merge options. In this way, the blame for the merged commits will always have a more recent commit date.
While choosing an option, you should take into account your development context. If you're importing several projects at once (bulk project import) using the Web API, it's important to know about the new code definition options and how they affect your analysis results.
Setting up the analysis
You can now set up your main branch analysis in SonarQube Community Build. See Project analysis setup.
To learn how to set up analysis in your IDE and with SonarQube Community Build, refer to the following links: SonarQube for IntelliJ, Visual Studio, VS Code, Eclipse.
Related pages
Was this page helpful?