Hello,
For our client we are currently going through a re-architecture. To properly isolate new code, we set up a new project in their Azure DevOps organisation, and we’re trying to link this new project to their existing SonarCloud.io account.
- The SonarCloud.io app can see all projects in the existing projects we had before.
- We created a new Azure DevOps project called
Singularity, this does not show up in SonarCloud whatsoever.
- I added a new Service Connection in this project for SonarCloud:
- Using my personal PAT: verification succeeds, no projects showing
- Using a scoped organisation access token: Verification fails when verifying the token for the Service Connection
- Currently pipelines in the new project fail because they cannot find the project in SonarCloud
- But SonarCloud doesn’t allow me to add the projects.
The documentation isn’t helping much either, nor are we getting any sensible errors outside “Something went wrong” during the token validation. Trying to validated the Scoped Organisation tokens manually using the API results in failure as well.
How are we supposed to make a new Azure DevOps project accessible for SonarCube cloud?
Hello @Arne_De_Herdt,
Welcome to the Community! And thanks for the details.
The Azure DevOps Service Connection you’re configuring authenticates your pipeline to SonarCloud, it’s not what controls whether a new ADO project shows up in SonarCloud’s “Add project” list. That’s driven by the org-level DevOps Platform Integration binding configured in SonarCloud itself (Organization Settings → DevOps Platform Integration → Azure DevOps), which uses its own PAT to enumerate your ADO projects. See Importing Azure DevOps organization for how that binding and PAT are set up, and Setting up Azure DevOps integration for your project for the project-level side once a repo is visible.
On the two specific symptoms: the scoped organization token failing verification in the Service Connection is a known, currently open issue, the Verify action calls an API endpoint that doesn’t support project-scoped tokens, even though the token itself may work fine for actual analysis runs. You can generally ignore that Verify failure if you’re using the token for the pipeline, or fall back to a full-access token just for verification purposes.
The personal PAT succeeding but showing no projects usually means the PAT’s underlying Azure DevOps account isn’t a member of the new “Singularity” project (or has Stakeholder rather than Basic access there). Since ADO permissions are project-scoped, the account backing SonarCloud’s org-level binding needs explicit access to each project you want it to see, being an org owner doesn’t automatically grant this. The Importing Azure DevOps organization doc covers the recommended account setup (dedicated technical user, Basic access type, added to the Contributors group, Code Read & Write scope on the PAT).
A few questions:
- Is “Singularity” in the same Azure DevOps organization that your SonarCloud organization is already bound to, or a different org/tenant?
- What Azure DevOps account is used for SonarCloud’s organization-level PAT, is that account added as a member of the Singularity project, and with Basic (not Stakeholder) access?
- Has that org-level PAT expired or been regenerated recently, since Azure PATs expire and force re-auth after 30 days of inactivity?
- If you add the SonarCloud technical account to Singularity’s Contributors group directly, does the project then appear in SonarCloud’s “Analyze new project” list?
- And as a workaround, does manually creating the project in SonarCloud (rather than importing via the ADO list) let you proceed, even if not ideal long-term, see Getting started with Azure DevOps for the overall import flow this bypasses.
Best regards,
Stevan
Yeah we found the account finally that set up the original PAT and resolved all access issues.