Azure Devops Quality Gate stay pending

Hello Anthony,

Another thing to check maybe is, have you set the same organization name in both your token setting (the screenshot you sent) and in your organization settings in Sonarcloud ?

I see in the log different values for your organization name (I sent you a private message with the values)

5111e6610eda8896080f54c62d0792384f0d93b6

Hello Quentin,

It has been 2 months now that our teams are blocked on this subject.

The development team has disable SonarCloud on their pull request to avoid being blocked.

We have done all possible tests, enter the provider and the PAT at the organization level, at the project level, both at the same time.
We tried several different PATs in full access or specifying the permissions as on the documentation.

This can’t be a PAT problem because it is used at the organization level and works for other teams / other scans. This is the PAT for a full access service account that expires in 2024.

I did a test today (ID: AYZzsrP9fqUJ6v8rqnkP By svcprodalm72718) and the pull request is still pending. Is it possible to check why?

If needed we can give access to our instance for debugging

Translated with DeepL


Hello Kevin,

What happens there is that your Azure Devops endpoint returns a 401 when we do a call to get the list of PR open (to then post the analysis result on the correct PR), I checked the latest test you just did and it is the same issue than all the other test previously.

So, there is something happening in your Azure Devops settings that prevents us from calling it.

I shared with Anthony the exact request we do to Azure Devops, as a CURL request, so you can also test the request between your computer and Azure Devops (no SonarCloud involved) and see if it works, because if it doesn’t work, there is something wrong happening on Azure Devops side that we can’t fix on our side.

I will share with you the request (in private message) as well so you can also have a look.

I am trying to help you figuring out what settings might be wrong in your Azure Devops instance.
Is there any chance you have Conditional Access enabled ? That could prevent us from calling your Azure Devops instance : What is Conditional Access in Azure Active Directory? - Microsoft Entra | Microsoft Learn

Hello Kevin, Anthony

We did some more investigation, we accessed our prod instances and made a few tests with your PAT.
It seems the PAT is indeed correct and we are now investigating an issue on our side.

We will come back to you as soon as possible with more info once we have some.

1 Like

Hello @Nunzo and @afabis ,

We can see here that you have a PAT configured also at project level. I understood that so far we talked about the PAT at organization level and we tested that this one is ok.

Could you please go to your project, Administration, General Settings then Pull Request section. Then please click on “reset” for the PAT that is stored at project level. It must looks like this:

After doing that please try again with a new analyse and let us know if it solves your problem or if you see something different.

Hello @Alexandre_Holzhey ,

As you suggested we have reset the project pat on project level and we got back into testing.

The issue still remain :frowning_face:.

Thanks for you help. Could you please provide me with the analysis id for this failing test you did? I would need the date and time when this was done as well, so i can find the logs.

Here’s the analysis Id : AYaEFXJPe4S5GTFk2YD8

This analysis was completed the 24/02 at 16:40 (4:40 PM EST)

1 Like

Hello @afabis

Is everything alright since our last private message ? Were you able to check the specific permissions of your PAT that we suggested ?

Let me know if everything solved on your side and if you have any feedback for us.

Best regards,

Hello, sorry I was away for a couple of days.

Yes ! We did find out what the problem was, In the repositories permissions parameters on Azure Devops we did setup the global permissions accordingly to what we needed for the Sonar Quality Gates.

But we did find out that the problematic repositories had their inheritance parameters checked to false (in the Security tab), making so that they couldn’t inherit the permission’s parameters, we checked it back to true and the connection now work properly.

image

Now everything seems to work, thank you for your assistance.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.