Status: To Do
In most CI environments (except those for which we have an integration), users must configure their builds manually, and for need to do know all the various properties to set and what to set on them. The process is not straightforward for users, sometimes needs scripting and is complex. This slows adoption for branch and PR analysis.
Let's make our users' lives easier by automatically configuring as much as possible from the environment.
We want automatic configuration in most popular CI:
- Azure DevOps Pipelines
- Bitbucket Pipelines
So as a developer, I would just need to:
- Generate a token,
- Make it available in a SONAR_TOKEN environment variable,
- Create another SONAR_URL environment variable to specify "https://sonarcloud.io"
- Inside my CI file: add the execution of a scanner without passing any extra parameters,
and I would expect to have all the branches and PR correctly analysed in SonarCloud.
To make this move easier, we want to take the opportunity to push 2 things:
- Drop the auto-provisioning
- Scanners will not be able to push analyses to non-existing projects anymore, users will have to set up the projects through the Web UI first
- We will add an empty but mandatory "Default branch name" field in the "Setup Manually" form so that if users go that way, then they need to clearly specify the name of their default branch
- The tooltip should guide the user by giving some examples, like "master" or "develop"
- Make the scanner engine know the SONAR_URL env variable
- The purpose is to not require to set "-Dsonar.host.url=https://sonarcloud.io" in every CI file
For the 3 first CI, we already have auto-configuration thanks to the integrations that we developed. The idea here is that this automatic configuration is not managed by the integration anymore but by SonarCloud scanners themselves
- We need to implement this feature and deploy it
- And then update the integrations
Main points about this feature:
- Auto-configuration will be a project setting
- For every new project: this auto-configuration will be active
- May it be for bound or unbound new project, it will work correctly since in both cases we will know the default branch
- For existing projects: this auto-configuration will not be active, users will have to activate it
- And when we detect that a project is analyzed on a supported CI, then we create a warning in the UI with a link to a doc page to help know what to do
- There are some exceptions to take into account for existing projects:
- if we detect that an existing project is analyzed with the Travis Add-on or Azure Pipelines (which use SONARQUBE_SCANNER_PARAMS to pass br/pr properties), auto-configuration should be activated (so that it works when we drop it inside the extension themselves)
- if we detect that an existing project is analyzed with Bitbucket Pipelines, auto-configuration should be activated (because this is how it works currently)
Note that even when auto-configuration is activated on a project and that project is run on a supported CI, the scanners should keep on considering properties which might come from the config file or the CLI. This is mandatory to give us flexibility in case of unexpected corner cases.