We are running a self-hosted GitLab together with a self-hosted SonarQube. SonarQube documentation instructs us to use a technical user when integrating SonarQube to GitLab:
Personal Access Token: A GitLab user account is used to decorate Merge Requests. We recommend using a dedicated GitLab account with at least Reporterpermissions (the account needs permission to leave comments). Use a personal access token from this account with the api scope authorized for the repositories you’re analyzing. Administrators can encrypt this token at Administration > Configuration > Encryption. See the Settings Encryption section of the Security page for more information. This personal access token is used to report your quality gate status to your pull requests. You’ll be asked for another personal access token for importing projects in the following section.
Now, GitLab does have technical users, in GitLab terms, bot users, that are created when you create group access tokens or project access tokens. However, SonarQube’s GitLab documentation is unclear on whether technical user refers to these or just regular user accounts not associated with a human.
As the docs are ambiguous, I went looking around in the forums and found these posts
I believe they suggest we cannot use group or project access tokens. Am I correct?
It would be nice if you could update the docs to be less ambiguous here, explicitly mentioning whether bot users work or don’t.
In our use case, since the SonarQube instance is not GitLab-wide but only used by one of our groups, group access token would be a perfect solution, as it does not use a seat (meaning it would be quite a bit cheaper for us!), not to mention the hassle of having an actual user with passwords and 2FA etc.
I’m not understanding the distinction between a bot user and an account not associated with a human.
What’s meant in our docs by “technical user” is an account not associated with a human, which would presumably be a “local account”, i.e. one not managed by e.g. LDAP, GitHub, etc., but stored locally in the SonarQube DB (altho, I suppose it doesn’t have to be local).
The three threads you cite relate directly to SonarCloud - where you, as a user, wouldn’t be able to create a local account - and thus aren’t directly relevant to your questions.
Ehm… I’m not quite understanding this question either.
You won’t be able to generate a “group” token. Only user accounts have tokens. User accounts may or may not tie to human beings.
For any user account (with relevant permissions), you may create a project analysis token. Such tokens work only for analysis of the specific projects they were created for. User accounts with global analysis permissions may also create global tokens.
You won’t be able to generate a “group” token. Only user accounts have tokens. User accounts may or may not tie to human beings.
Gitlab does have group tokens. These can be generated at the root group, or sub-group level.
A “technical user” is in effect a shared account. In the SaaS Gitlab, this is counts as a seat and we are paying for a user even though we are just using it to create the link to Gitlab. The bot users are automatically created by Gitlab when a group, or project, token is generated. They do not count as a seat and are not charged for.
I think that the Group/Project and user access tokens should suffice. The only real difference is that annotation of the merge requests will should the Bot username.
This area has changed within Gitlab over the past couple of years, and it might be that the Sonarcloud guide was written before the advent of this new tokens. In any event, with the change by Gitlab to remove never expiring tokens, this is now something that will be looked at more.
Using a Gitlab group access token, from our root level, works. The only difference we can see is the name of the annotator of the Merge Request comment:
You are correct SonarQube does not have group tokens. However, here we are looking at providing access for either SonarQube, or a SonarCloud tenancy, at the integration level rather than at the user level.
At this level the recommendation is to create “Technical User” within Gitlab in order to be able to create a personal access token to provide the linkage. This is no longer necessary in Gitlab and Group access tokens provide a better solution by removing the need for the “Technical User”.
