GitLab Token Exipired - Cannot Be Updated

[elvedinbabic (Elvedin)]

Cannot update token for GitLab - so binding does not work

[Colin]

Hey there.

I just went to my org-level Administration > Organization settings > Organization binding and bound my org with a new token.

What happens when you try to update the token?

[elvedinbabic (Elvedin)]

I get: Failed to get Gitlab namespace 404. I also get following when trying with new org: Missing required parameters. Provide either organizationId OR (devOpsPlatform and installationId) OR (devOpsPlatform, devOpsPlatformOrganizationId parameters and DevOps-Platform-Access-Token header).

[Colin]

Could there be some network filtering going on?

Unable to import Azure DevOps Organization in SonarQube Cloud

Hello, We had a few users reporting this and it turned out to be an issue with their network policy. It was filtering the request and removing the ADO token that is passed as a header. Those use ZScaler. Do you use ZScaler or a similar network filtering solution? To confirm, can you try outside of your corporate network to validate that this is the problem? Regards, Antoine

[JackWhelpton]

Sorry to resurrect a zombie thread, but I may have a bit more info on this… we were trying to use a Personal Access Token from a GitLab Service Account (rather than a paid user seat, that also has to be updated if that user leaves etc.) and that results in this error.

Using a “standard” PAT works fine. Is there a way to use access tokens tied to service accounts to configure the ALM integration?

[Colin]

Hey @JackWhelpton

This error exactly?

@elvedinbabic

Provide either organizationId OR (devOpsPlatform and installationId) OR (devOpsPlatform, devOpsPlatformOrganizationId parameters and DevOps-Platform-Access-Token header).

Sounds really weird if so. Are tokens generated by the access account in a different format than the “standard” ones? A different prefix or something?

[hsb-guido (Guido)]

I ran into the same issue today. Similar to what Jack Whelpton experienced.

Previously, I used a Gitlab Group Access Token. I tried to move to a Service Account Access token instead and failed to update the Access Token in Sonarcloud.

My issue is solved by explicitly giving the Service Account permissions to the relevant Gitlab Group(s). Apparently, the Service Account has no permissions, even if it’s created within a Gitlab group.

[JackWhelpton]

Thanks @hsb-guido , that was exactly the problem! I think I’d tacitly assumed the service account would pick up some default permissions, but it makes sense that should be managed using the same path as for non-SA users.