In SonarQube Server, the branch analysis allows you to trigger an analysis on a push to any specified branch without involving pull requests.
*Branch analysis is available starting in Developer Edition. *
To set up the Introduction:
Add the analysis step to your multi-branch CI pipeline. See the corresponding section of your CI tool in this documentation:
Make sure the branch to be analyzed is properly checked out in the CI repository: see Checked-out code.
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.
Limit the analysis to the relevant branches: see Limiting the analysis to the relevant branches below.
Configure the new code settings for the branches: see Configuring the new code settings for branches below.
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
Codemagic
GitHub Actions
GitLab CI/CD
Jenkins (with the Branch Source plugin configured, see Setting up Jenkins page)
The table below shows the branch name parameter. See Analysis parameters for information about the setup of analysis parameters for the scanner.
Parameter Name
Description
sonar.branch.name
Name of the branch (visible in the UI)
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/*.
Look at the Introduction 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 the About new code page for more information.
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.
Last updated
Was this helpful?
Was this helpful?
if [[ "$CI_BRANCH_NAME" == main ]] || [[ "$CI_BRANCH_NAME" == release/* ]]; then
./gradlew sonarqube
fi