Getting started with GitLab
If your code is on GitLab, go to the SonarCloud product page and choose Set up or Login, then select GitLab from the list of DevOps cloud platforms.
You will be taken to the GitLab login page. Sign in using your GitLab credentials.
Welcome to SonarCloud
Once you have successfully logged in, you will see the SonarCloud welcome screen. Select Analyze your first projects > Import an organization from GitLab.
Set up your organization
Connect your GitLab group with SonarCloud
First, select either
- Import any GitLab group, if you want to import a GitLab group other than your personal one, or
- Import my personal GitLab group, if you want to import just your personal group.
If you select the first one you will need your GitLab group key and a personal access token.
If you select the second one you will just need a personal access token.
For the group key, you can provide either the ID of the group or the key of the group. The group ID can be found under the group name on the group page. The group key is the last element in the path of the group and is found in the URL. For example,
Note that the user that is logged into SonarCloud must be an owner of the GitLab group.
We currently only support the importing of GitLab parent groups. Subgroups are not supported.
Personal access token
To create the token, go to User settings > Personal Access Tokens in GitLab, or while logged in to GitHub, click the Personal Access Token hyperlink in the SonarCloud Create an organization tutorial.
When creating your access token on the GitLab User settings > Personal Access Tokens page, make sure to select api scope. Then click Create personal access token.
When the personal access token is displayed at the top of the page, copy the token and paste it into the field on the SonarCloud setup page.
An api scope is required
SonarCloud requires that the access token have
api scope. This gives SonarCloud more access rights than strictly necessary, but due to the lack of more fine-grained access control in GitLab, it is the only viable option.
To mitigate this potential security concern, we strongly encourage you to add a technical user to your organization, log in to SonarCloud using that technical user, and use the access token of that technical user to connect your GitLab group to SonarCloud.
SonarCloud will always limit its actions to those required for effective integration with GitLab and will never use the full access right provided by the
Create your SonarCloud Organization
SonarCloud is set up to mirror the way that code is organized in GitLab (and other repository providers):
- Each SonarCloud project corresponds one-to-one with a GitLab project, which resides in its own Git repository.
- GitLab projects are grouped into GitLab groups.
- Each SonarCloud organization corresponds one-to-one with a GitLab group.
In this step, you will create a SonarCloud organization that corresponds to your GitLab group.
SonarCloud will suggest a key for your SonarCloud organization. This is a name unique across all organizations within SonarCloud. You can accept the suggestion or change it manually. The interface will prevent you from changing it to an already existing key.
SonarCloud supports one DevOps platform at a time.
SonarCloud does not support linking an organization to more than one DevOps platform. If you want to link to more than one, you will need to create a separate organization to link to each DevOps service.
Choose a plan
Next, you will be asked to choose a SonarCloud subscription plan. If all the repositories to be analyzed are public on GitLab, you can select the free plan. When using the free plan, your code and analysis results will be publicly accessible at sonarcloud.io/explore/projects.
If you want to analyze one or more private repositories then you need to select a paid plan. All paid plans offer a 14-day free trial period. Once the 14 days have elapsed, the cost is based on the number of lines of code analyzed.
A plan is always associated one-to-one with a SonarCloud organization and therefore with a single GitLab group. If you want to onboard multiple GitLab groups, you must sign up for a separate plan for each.
Once you have chosen a plan and clicked Create Organization, your SonarCloud organization will be created!
Set up your analysis
The next step is to import the projects (that is, individual Git repositories) that you want to analyze from your GitLab group into your newly created SonarCloud organization, creating a corresponding SonarCloud project for each.
SonarCloud will present a list of the repositories in your GitLab group. Select those that you want to import and analyze and click Set Up.
The selected projects will be imported.
With GitLab projects, the actual analysis is performed in your build environment (cloud CI, local machine, etc.). This means you have to configure your build process to perform the analysis on each build and communicate the results up to SonarCloud.
We refer to this analysis method as CI-based analysis (though it may take place in a cloud CI or a manually configured build environment) to contrast it with automatic analysis which works by SonarCloud directly accessing your repository and performing the analysis itself. However, automatic analysis is currently available only for GitLab projects and only for a subset of languages. It is currently not available for GitLab projects.
SonarCloud will guide you through a tutorial on how to set up your build environment to perform analysis.
The first step is to select your build environment. SonarCloud will present this page:
If you have no particular preference and are setting up a new project on GitLab, we recommend using GitLab CI/CD as your CI.
Follow the tutorial to set up your analysis.
See your analysis results
Once it is complete, you can view the results of your first analysis.
In addition, please see the page on GitLab CI to integrate SonarCloud into your GitLab pipelines.
If you log into SonarCloud using an email address that you previously used to log into another DevOps platform, you need to be aware that SonarCloud will automatically associate your email address with the new DevOps platform. For example, if you log in through GitLab and previously used GitHub, GitHub issues will no longer be assigned to your email address and you will stop receiving GitHub email notifications. If you then decide to switch back to GitHub, the GitLab email notifications will be discontinued.