Set GitLab personal access token via properties file or environment variable

To configure GitLab pull-request decoration, a Personal Access Token must be provided via UI.

When the Sonarqube instance is deployed from a CI, it’s very common to use it as an environment variable, that eventually may be used to override sonar.properties file content.

Although is secure, I would like to be able to provide this token as an environment variable, or even being able to set via property (e.g. sonar.gitlab.token.secured)

Hi @fsmaia, welcome to the SonarSource Community!

I’m curious about how/why you deploy SonarQube itself via CI. You do this automatically and regularly? For what reason, compared to simply leaving it up and running?

We generally only support config file or environment variable-based configuration for values that are involved in SonarQube’s own startup. GitLab PR decoration is more of a user-level feature so its settings are made via the UI and stored in the database.

However, you may achieve your desired result if you make a call to our web API. The call to make would be api/alm_settings/update_gitlab. API documentation is embedded in your SonarQube instance; see the link “Web API” in the footer of each page in the UI.

In our scenario, all the applications and services are deployed with Kubernetes clusters, using Helm charts. Although the K8s setup is especially useful for scaling, there are lots of infrastructure abstractions that make it worth it.

IMHO it’s hard to tell it if is a setting or a runtime feature, but you definitely have a point. Personally, I see it more like a setting, since it’s a unique static value and a part of the SCM setup.

Another reason to accept an environment variable is that the token value is sensitive. In some scenarios it is not even possible to retrieve the raw value after the creation, leading users to delete and recreate the token just to paste it in the Sonarqube.