Setting up the branch analysis

Branch analysis is available starting in Developer Edition. 

To set up the branch analysis: 

1. Add the analysis step to your multi-branch CI pipeline. See the corresponding section of your CI tool in this documentation:
   • Jenkins
   • Azure Pipelines
   • Bitbucket Pipelines
   • Codemagic
   • GitHub Actions
   • GitLab CI/CD
2. Make sure the branch to be analyzed is properly checked out in the CI repository: see Verifying the code checkout step. 
3. Make sure that the SonarScanner gets the branch name parameter (otherwise the analysis will be performed on the main branch): see Setting up the branch name parameter below.
4. Limit the analysis to the relevant branches: see Limiting the analysis to the relevant branches below.
5. Configure the Clean as You Code settings for the branches: see Configuring the CaYC settings for branches below.

Setting up the branch name parameter

The SonarScanner can automatically detect the branch name parameters when running on the following CI services (you don’t need to perform any additional setup):

• Azure Pipelines
• Bitbucket Pipelines
• Cirrus CI
• Codemagic
• GitHub Actions
• GitLab CI/CD
• Jenkins (with the Branch Source plugin configured: see …)

The table below shows the branch name parameter. See Analysis parameters for information about the setup of analysis parameters for the scanner.

Limiting the analysis to the relevant branches

You need to add a condition to your pipeline script to ensure that only the relevant branches are analyzed. For example, you wouldn't want to run analysis on feature branches that won't need analysis until they have pull requests.

In the following example, analysis would be limited to branches named main or release/*.

if [[ "$CI_BRANCH_NAME" == main ]] || [[ "$CI_BRANCH_NAME" == release/* ]]; then
  ./gradlew sonarqube
fi

Configuring the CaYC settings for branches

Look at the Clean as You Code strategy to learn how to implement this best practice.

The quality gate cannot be configured at the branch level, only at the project level. And ideally, all projects will use the same quality gate: see Quality gates.

You can set a new code definition for each branch. This is especially helpful if you are likely to develop and release multiple versions from the branch. See the Defining new code documentation for more information.