We have an integration set up for GitLab and Bitbucket. Recently our projects imported from GitLab started showing an error regarding permission scope of the personal access token used on the settings page.
When looking at the global settings, as referenced in the error, all is OK. The user is an admin user with access to all project in our GitLab instance.
You have the following errors in your configuration:
The personal access token has been created with a user with insufficient permissions on the project. Requires at least REPORTER role permission.
Please check your global settings.
Already tried to replace the token with a new one.
It’s confusing since on GitLab you’re not able to scope a personal access token to a specific role. Only project and group access tokens can be scoped to a role. Personal access tokens | GitLab
We had an issue reported internally where, for some reason, one of our pre-sales engineers needed to add both readandread_api permissions to the token. The issue seemed to resolve itself (perhaps something on GitLab’s side).
If you’re still facing the issue, can you give this a try?
I tried recreating the token with those 2 scopes, didn’t seem to resolve the issue. Also tried a token with all scopes added. Same result.
Might this happen since the user is an admin user and not directly added to any groups or projects? It can view the groups and projects in the explore tab tho.
If this was always the case for your admin user, then I wouldn’t expect the behavior to change overnight.
I would suggest checking the log files (specifically web.log) when you try to verify the configuration to see if any more detailed errors appear than what you see in SonarQube. You can also raise the log level if needed via the global Administration > System > Log Level
This seems to be a recent behaviour changed in Sonar (or perhaps Gitlab). I’m on Sonar Version 10.0 (build 68432) and Gitlab 15.11.6 and I’m not sure when it started.
It is related to the Gitlab user not being added explicitly to all repositories.
There’s an API call to Gitlab [o.s.a.c.g.GitlabHttpClient] get project : [https://gitlab.example.com/api/v4/projects?min_access_level=20&id_after=9999&id_before=10001] which returns no projects unless the user was added to the project Members, even if the user is admin and has access to everything.
Removing min_access_level=20 from the query properly returns the project.
thanks for reporting this. Indeed, it looks like Gitlab administrators can’t search for projects using the min_access_level filter, which would require them to have an actual membership in the project (or one of the parent group).
Workaround is to add the Gitlab admin to top-level groups, or to every project that needs MR decoration from SQ.
I want to point out that “only” the validation is failing: since the Gitlab admin actually has permission to comment on the MR of any project, the SQ <> Gitlab integration will work, and MR will get decorated. (The feature works, but not the validation). This is something we can improve, and I created a bug ticket on our side to work on.
On the other hand, I’d personally discourage you from using a Gitlab global admin personal access token for the SonarQube integration: Following the principle of least privilege, only the Reporter Permission is needed. You could create a dedicated user, having only the Reporter permission, add this user to the groups, and that will work.
