Link DevOps Platform Integrations with Gitlab to a project for MR decoration
Since we upgraded to the latest LTA we get a {“message”:“Personal access token for ‘Gitlab’ is missing”} response with 400 code.
However, the token is present and the integration still decorates the MRs that were configured before the upgrade to the latest LTA. When navigating to Global Settings → DevOps Platform Integrations we can see that the gitlab configuration is marked as green and stating “Configuration valid”.
I’m trying to set up the Gitlab project ID. Must say I have admin privileges ofc, MR decoration is working fine on other projects, and when I check config whether on other projects or in Administration menu seems to work fine.
The issue is associated with a lack of/a stale user-level GitLab PAT. The workaround is to go to the main projects page > Create Project > GitLab, and this screen will prompt you for a PAT. Generate it as instructed, and then go back to the project settings and retry the project binding. It should now work. Can you try this and confirm that it solves the issue?
The improvement we’re tracking (will be delivered as a patch to 2026.5) is to enable this PAT input directly from the project-level integration settings.
Thanks for your inputs Andrés, is it possible to automatically re-use the Gitlab PAT defined at Sonarqube Server level in order to allow configuration of devops platform integration for a given project? That would be much simpler than inputting a PAT everytime we need to configure devops platform for every project.
Hey @manujimenez, no it’s not possible and it’s deliberate. The org-level PAT enables certain features but not this in particular, because we want a given user to only be able to bind the project to a repo they have permission over in GitLab/other. The token used for the org-level binding might have visibility over repos that the user doesn’t.
I understand the security rationale, but I think this is a significant regression in usability for organizations like ours.
We already have a GitLab PAT configured and managed at the SonarQube Server level. Until now, this was a straightforward and convenient way to manage our DevOps integration. With this change, we are now expected to ask every user who needs to bind a project to GitLab to create and manage their own personal access token. On top of that, the current workaround is rather cumbersome.
I understand that the global PAT may have access to repositories that an individual user cannot access. However, I believe this should be a choice for each organization, rather than a restriction imposed on everyone.
Could this be made configurable at the administrator level? For example, an option to allow project bindings to use the global GitLab PAT, while keeping the current user-level PAT requirement as the default or as an alternative for organizations that need stricter access control.
This would preserve the security model for organizations that require it, while allowing others to retain the simpler workflow they have been relying on.
The current approach shifts the burden of managing access tokens to every individual user, even in organizations where repository access is already centrally managed and controlled. I think giving administrators the choice would be a much more flexible solution.
