Organization binding resolves GitLab group by path — breaks after group re-parenting (group ID uncha

Hello,

Our organization can no longer list its GitLab repositories, so project binding and MR decoration are broken. Analyses themselves are received normally.

  • Organization key: truckfly
  • Project key: 30576796 (private)
  • gitlab.com (not self-hosted)

On 2026-05-12 we moved our GitLab group under a new parent. The group was not recreated — only its path changed:

  • old path: truckfly (top-level, now 404)
  • new path: truckfly-product/truckfly
  • group ID: 13904470 (unchanged)
  • new parent group ID: 132128336

Organization binding shows Bound with a Valid PAT (api scope, owner is Owner of both groups), but Repository binding returns No repositories found for this organization.

Since the group ID never changed, the binding should have survived. It appears to resolve the group by path rather than by numeric ID, so it now points at a path that 404s and list_repositories returns nothing — while the UI still reports the binding as valid, which makes this very hard to diagnose.

This isn’t self-serviceable: the UI states a binding cannot be undone, and there’s no way to update the group reference. The same case was fixed manually in Renaming group in Gitlab breaks some links in SonarCloud: in post #11 Nawar_Hamo removed the binding so the user could re-bind from Administration → Organization settings, and in post #13 advised re-binding with the numeric Group ID.

Could you remove the binding on organization truckfly so we can re-bind it to group ID 13904470?

To be explicit, as this came up when we contacted Sonar directly: we are not asking to bind two groups to one organization. One organization, one group, unchanged — only its path moved. A second organization would mean a new project key, a second subscription and the loss of our analysis history.

Thank you.

Hey @mpetrini, welcome to the Community! I will flag this for the team, hopefully they can intervene and make the switch.

I understand that you initially bound it by telling SonarQube Cloud the group name instead of the ID. However, it is strange that the UI shows “bound with a valid PAT” if the group really moved and there’s nothing at the original path. Maybe the team can also check if this is expected or not.

Finally, just FYI, we aim to support better org un-binding and re-binding in the future (next quarter perhaps), which should ease cases like this.

Hi Mathieu,

I have removed the GitLab binding from your existing truckfly organization.

The old binding was recorded as a personal GitLab namespace. SonarQube Cloud therefore looked for repositories under a GitLab user account. This explains why the token appeared valid while the repository list was empty.

You can now bind truckfly to your GitLab group at truckfly-product/truckfly. Select Import any GitLab group during setup. You can then select the repositories for your existing projects. Your projects, subscription, and analysis history remain in place. You do not need to create another organization.

We’re very sorry for the trouble; please let us know if you have any questions or need help with the binding steps.

-Scott