I have tried numerous times to set up an account in SonarQube Cloud and link it to our Bitbucket account. I have tried with several different accounts for Bitbucket, all with admin access. Here are the steps I have followed:
It then prompts me to select my cloud repository solution for “1-click signup” - I select Bitbucket
I am then taken to a screen with a button titled “Import an organization” - I click that
I then see a screen showing my Bitbucket login email, and a dropdown list of workspaces in my Bitbucket account. We only have one, so that one is selected. I then click the “Grant access” button.
It then takes me to the SonarQube Cloud UI and is on a page titled “Create an organization“. Then it shows the following error message:
We were not able to find the requested organization, here are a few tips to help you troubleshoot the issue:
You must be an administrator of the organization
Try to uninstall and re-install the SonarQube Cloud App (using the button bellow)
I have tried this many times. This process does successfully add the SonarQube Cloud app to our Bitbucket account, so I know it has access to it. However, it always gives the same error. I have deleted the app in Bitbucket and tried again, to no avail. I looked at the API calls in Chrome’s inspector, and the one API call that shows an error is: https://sonarcloud.io/api/alm_integration/show_dop_organization, which returns a 500.
Any help would be greatly appreciated. We cannot even sign up for a paid account because of this error.
Interestingly, an immediately preceding request was successful and returned a 200 status, but that request used is_private=true instead of is_private=false:
Since 12 hours have passed since the last occurrence, could you try sending the request again to see if the issue has resolved? Sometimes these situations clear themselves up after some time.
I am not sure where you got the idea that it was returning a 429. The only API call returning an error is https://sonarcloud.io/api/alm_integration/show_dop_organization, which returns a 500 consistently. I’m guessing that it’s the issue, but not sure. But even if that is the issue, how do I get around this error?
In the SonarQube Cloud backend, when you call GET api/alm_integration/show_dop_organization, SonarQube Cloud makes a call to Bitbucket, and that call to Bitbucket is returning a 429.
I’m guessing that you’ve tried again and the issue is persisting?
Yes, I’ve tried it again, and it still doesn’t work. But I am still confused as to how you would know that the call from SonarQube Cloud to Bitbucket is returning a 429 when I can’t even see that in my environment. How could one know what API calls are happening behind the scenes between SonarQube and Bitbucket because that doesn’t flow through my browser. There are no calls to Bitbucket with an error. In fact, the only error for any API call is the one I mentioned above. There is no 429 return anywhere.
Ultimately, I have access to the backend logs, where I found your request and I can see where the request you make to GET api/alm_integration/show_dop_organization proxies a request to Bitbucket, and Bitbucket returns a 429.
I’m phoning a friend – they might have a better idea.
Thanks @Colin, that explains it. I didn’t realize you had that access. I would appreciate any help you could give. I tried working through the sales rep, and he finally said he couldn’t help because we weren’t a paying customer, and their tech support wouldn’t help us because of that. Oddly, we were trying to become a paying customer but couldn’t get past this issue.
We do have almost 250 repos in Bitbucket, so maybe that’s the reason? Of course, I’m not sure what to do about that - we can’t just delete repos.
Sorry for our late answer. Although it’s not clear from their API Rate limits documentation, BitBucket implements a per-workspace limit for some of its API resource.
The documentation states that API requests are measured against the authenticated user or the OAuth consumer. Since all apps installed on a workspace act on behalf of the workspace, their requests are pooled together and draw from the same hourly limit.
The resource we need here (/2.0/repositories/*) is heavily monitored, because critical, and has a scaled rate limit mechanism (ie. limit depends on your plan and number of user).
All in all, the point is that your workspace is consuming the API for other things and it prevents SonarQube to proceed with its usage when you install our App. The first thing to do here is identify the API consumers that might be at fault here: are they other Apps installed on your workspace? A typical heavy consumer will be a CI/CD tool for example.