SonarQube Cloud | Administering SonarQube Cloud | Resources structure in SonarQube Cloud | Binding with the DevOps platform

Binding with the DevOps platform

The binding is performed automatically by importing the DevOps organization and its repositories into SonarQube Cloud. Note that you cannot import repositories into SonarQube Cloud if the respective DevOps organization has not been imported into SonarQube Cloud.
If you create organizations or projects manually (i.e., without importing the DevOps organizations or projects), they are not bound with any peers on the DevOps platform. Manual organizations and projects are like empty containers identified solely by their keys, which you choose when you create them. They are only linked to your code by you explicitly setting the analysis parameters sonar.projectKey and sonar.organization to those keys in your CI-based analysis setup (Automatic analysis is not supported for manual projects).

You can bind an unbound project and you can bind a bound project to another repository.
You can bind an unbound organization but you cannot change the binding of a bound organization.

The binding presents many advantages as described below.

Advantages of bound organizations

The advantages of bound SonarQube Cloud organizations over unbound ones are:

Bound organizations enable the easy selection and import of projects into SonarQube Cloud (as mentioned above).
Bound organizations support automatic member synchronization (This feature is only supported with GitHub.).
Importing a project via a bound organization is the only way to create a bound project, and bound projects have their own set of advantages (see below).

The advantages of bound SonarQube Cloud projects over unbound ones are:

Automatic analysis is only available for bound projects (This feature is only supported with GitHub.).
The pull request decoration is automatically configured on bound projects if your CI tool is integrated with SonarQube Cloud.
Upon import, bound projects on the SonarQube Cloud side automatically adopt the privacy setting of their DevOps platform peer. Projects that are private on the DevOps platform remain private on SonarQube Cloud. With manually created projects, you must make sure to explicitly set the privacy status of your SonarQube Cloud project. This opens up the possibility of inadvertently exposing the code of a private project to the public through SonarQube Cloud.

Was this page helpful?