Using Scoped Organization Token in Azure DevOps service connection give InternalServerError

SonarQube Cloud
1

We are trying to move away from personal access tokens and instead use a Scoped Organization Token for SonarCloud.

Our SonarCloud organization contains 109 projects. We created a new Scoped Organization Token and explicitly assigned it to 3 specific projects. All these projects are private projects.

When we apply this token to our SonarCloud service connection in Azure DevOps (Edit Service Connection → paste new token → Verify), the verification fails with a server-side error.

We also waited some time after creating the token (in case propagation or initialization was required), but the error persists consistently.

The error we get is this one:
Failed to query service connection API: 'https://sonarcloud.io/api/organizations/search?member=true'. Status Code: 'InternalServerError', Response from server: '{"errors":[{"msg":"An unexpected error occurred. Please try again later."}]}'

Any help would be appreciated, as we would really like to adopt scoped tokens instead of personal ones. What can we do to make this setup work correctly?

Thanks in advance!

4

Hi @FreddyGroen,

Sorry for the late response.

Currently, Scoped Organization Tokens are only used to run analyses. So it wouldn’t work when querying https://sonarcloud.io/api/organizations/search?member=true

It is on the roadmap to add scope tho!

Cheers,

6

Hi @Guillaume_Peoch ,

So.. I must be doing something wrong then? Can you maybe guide me on how to set this up?
I think I’m going through the standard path for doing this. Or can I just ignore that error and continue?

Also, is there a non-community way to getting support for paying customers? I don’t mind doing it here, but there should at least be some minimal SLA on this?

Best regards,
Freddy

7

Freddy,

I must be doing something wrong then?

No, it’s because our Cloud SOTs can’t be used in an ADO Service Connection just yet.

Or can I just ignore that error and continue?

I strongly recommend using a PAT instead; @Guillaume_Peoch also shared his perspective:

“Verify” uses the candidate token to query our APIs; e.g., /api/organizations/search. SOTs do not yet work for these APIs, hence the InternalServerError.

Also, is there a non-community way to getting support for paying customers? I don’t mind doing it here, but there should at least be some minimal SLA on this?

On Help Center, our commercial SLA is between 1 to 24 hours, depending on the severity of the issue at hand. (There’s nothing like that on Community, of course.)

Best, Wayne

2 Likes
8

Thank you Wayne,

Is there any topic I can follow and get notified on when that functionality is compatible with ADO?

We are transitioning slowly to GitHub, it would help us getting rid of the PAT token usage in the meantime.

Best regards,

Freddy

9

Freddy,

There was a nice blog post on SOTs this past September. And if you scroll to the bottom, there is an email input box to subscribe if you wish. Personally, I don’t find it too spammy, and it helps me stay on top of product changes, in case I missed something :slight_smile:

Best, Wayne

3 Likes
10

Hey @FreddyGroen - thanks for sharing here!
I just wanted to chime in and let you know that I captured your need for SOT to support ADO service connection and that we’ve planned to work on this in a few months.
We will definitely share on community when it’s done!

2 Likes
12

Any update on this?

13

I would also like to move away from PATs for DevOps. So would be great if theres an upgrade on this

Edit: I see it should be working now if you just save the service connection without validation. An error is still thrown in the pipeline but the pipeline itself succeeds but its a known issue: Seeing an error “Error retrieving entitlements” since from last 3-4 days