In CI environments, the process to analyze branches and P/Rs is not straightforward for users, as it sometimes needs scripting and is complex. It slows down the adoption of branch and P/R analysis.
We want to make our users' lives easier by automatically configuring as much as possible from the scanner's running environment. Most CIs expose environment variables that could be used to automatically pick up values that are currently configured manually by, such as branch name and P/R ID. SonarQube already automatically applies such a mechanism when running with Azure Pipelines and GitLab CI.
This MMF focuses on Jenkins, for which we know the configuration process can be painful.
As a user who works with GitLab, GitHub or Bitbucket and uses Jenkins to analyze projects on SonarQube, I expect to be able to simply enable the analysis of my branches and PRs without having to pass on my own the branch and PR related parameters to the Scanner for Jenkins or to other SQ scanners used with Jenkins.
So, with this MMF, we want to automatically detect, in Jenkins, branch and PR parameters for users using SQ DE+ editions.
The auto-configuration should not impact the user experience for SQ CE and the upgrade from CE to DE+ should be the smoothest possible.
- Auto-configuration is deactivated - the CE only analyses one branch per design
- We assume that the branch analyzed is the main branch, whatever its name is. And the project has a single branch called "master" on SonarQube side.
- Branch and PR analysis come out of the box: analysis on any branch/PR are performed without any configuration: branch & PR parameters are auto-configured, meaning branch name, target and PR key are taken directly by the scanner from the CI
- By default, we currently only recognize master as the "main branch". Users who want another branch to be the "main branch" need first to provision the project and rename the "master" branch. This will be improved with MMF-1335. Later again, the default branch that is exposed by some CI as main branch could be prevalent to the default setup.
With the analysis of any branch/PR:
- the project is provisioned if it wasn't done yet, with an empty "main branch" called 'master' by default
- If the name of the branch matches the main branch in SonarQube, the main branch is updated
- otherwise the branch/PR is created or updated
- SonarQube will log a Warning message when it detects a branch/PR parameter while the auto-configuration is activated. The message will be logged only on the scanner side, otherwise it will be too noisy for users at migration.
- The PR parameters are tightly linked, as soon as any branch/PR parameter is passed, the "manual" configuration should keep applying (auto-detection is disabled).
- With this MMF, we won't decouple the project and the main branch creation. The main branch keeps being "master" by default.
- Do we want to store the CI on the server? -> as a criteria to measure the success
We want to keep the analysis of the main branch that is already configured and to keep its history.
- In CE, users analyze only one branch and cannot pass a branch name to analysis. The branch is displayed as "master" in SonarQube.
Once migrated in DE+, we can't know which branch was analyzed. Now, analysis may create a new branch depending on its name. Users who want to keep analyzing the branch as the "main branch" have to rename the main branch in SonarQube with the name of the branch they are analyzing.
- If analyses were launched with some branch/PR parameters, those parameters will still be taken into account -> no impact
- If the analysis of a branch was launched before migration without branch.name, it was previously analyzed as the "main branch" in SonarQube. Here again, analysis may now create a new branch depending on its name. Users who want to keep analyzing the branch as the "main branch" have to rename the main branch in SonarQube with the name of the branch they are analyzing.
The Release Notes and the documentation should explain that the main branch name should be correctly set for the auto-detection to not create a new branch when it's analyzed again.