Setting up Clean as You Code

As a project administrator, you set up Clean as You Code in three steps: 

1. You set the quality standard for your project.
2. You set a new code definition.
3. You set up pull request and branch analysis. 

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, you need to choose a new code definition.

Configuration levels

You can define new code at the global, project, or branch 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. If you're using an edition that supports multiple branches (starting in Developer Edition), what you define as new code at the project level will be the default for the project's branches.
• Branch level: If you're using an edition that supports multiple branches (starting in Developer Edition) You can define new code for each branch:
  1. Go to your project > Settings > New Code. 
  2. In the branches table, define your new code option in the Actions column.

Both project and branch-specific 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, project, and branch 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 reads the version from the pom.xml file.
• If the analysis is done with the SonarScanner for Gradle then SonarQube 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, project, and branch 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 branch (Developer edition and above) and project levels. 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.

Reference branch

Recommended for projects using feature branches. Available at the project and branch levels. Any differences between your branch and a selected reference branch (in the clone the scanner has access to at analysis time) are considered new code.

On the scanner side, it’s possible to use the sonar.newCode.referenceBranch property to apply the Reference branch option to the analysis of a branch, overriding the global new code definition set in the UI (see the Analysis parameters page for more information about setting hierarchies).

This setting is particularly useful during the first analysis when the branch to be analyzed does not exist yet in SonarQube. The sonar.newCode.referenceBranch property specifies the reference branch value.

Recommendations

• To avoid reference errors when cloning a repository, we recommend cloning all its branches.
• The Reference branch new code definition is useful for short-lived branch analysis before a pull request is created, or for short-lived branch analysis where pull requests are not in use (e.g. trunk-based developments). For the latest, the setting will also allow issues on the reference branch to inherit their status from your short-lived branch after its merge (see Issue management overview > issue synchronization between branches).
• When using any new code period type other than Reference Branch, 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

To learn how to set up analysis in your IDE and with SonarQube, refer to the following links: 

• SonarLint for IntelliJ, Visual Studio, VS Code, Eclipse
• Setting up branch analysis
• Setting up pull request analysis

Related pages

• Clean as You Code Introduction
• Clean as You Code overview