[solved] 500 error activating Bitbucket Cloud repository

I’ve setup drone 0.7 (also 0.8 with the same result) on AWS ECS using bitbucket cloud as source control provider. I’m able to login with my user but I can’t activate any repo because it gives me 500. I have tested this with both versions and have the same result.

Bitbucket it’s an organization repo and I’m an user with admin permisions on that org. I have successfully setup the OAuth consumer as I’m able to login to drone using my bitbucket user.

I have queried my user to drone and got this result:
{“id”:1,“login”:“cohandsiplay”,“email”:"",“avatar_url”:“https://bitbucket.org/account/cohandsiplay/avatar/32/",“active”:false,"admin”:true};

I see the active application drone inside my bitbucket account settings.

I don’t have any clue on how to follow or troubleshoot this, I’d apreciate some help with this.

Thanks
David

1 Like

Unfortunately Bitbucket error messages are a bit lacking, but below are some common reasons that activating a Bitbucket repository will fail. Note that you can also check your drone server logs, which may provide some more details.

1. Not enabling all of the following Bitbucket scopes when you registry the application:

Account:Email
Account:Read
Team Membership:Read
Repositories:Read
Webhooks:Read and Write

2. Not having admin access to the repository in Bitbucket. This is required in order to create the webhooks

3. Using Drone with a private URL or address. Bitbucket will error if you try to create a webhook at a URL that it cannot reach. This includes localhost.

1 Like

I have double checked all those three common errors and looks well configured. Another idea? Something I can post to better understand the error?

What about this settting on bitbucket?

This is a private consumer

I just created a repo under my user and got the same result (I can see the new repo, but can’t activate it) which makes me wonder, the oauth consumer at what level should be set?

I have set the oauth consumer at the org setting not the user setting (which makes sense to me since I won’t be the only one managing drone builds, but made me wonder if would be related

You mentioned that you get a 500 … can you check the HTTP message response? The error message should be included in the response body. If it does not surface the message in the UI you can check the chrome developer console / network monitor.

General
Request URL:http://drone.siplay.io:8000/api/repos/siplay/sipbot
Request Method:POST
Status Code:500 Internal Server Error
Remote Address:172.20.130.4:8000
Referrer Policy:no-referrer-when-downgrade

Response Headers
Access-Control-Allow-Origin:*
Cache-Control:no-cache, no-store, max-age=0, must-revalidate, value
Connection:keep-alive
Content-Length:11
Content-Type:text/plain; charset=utf-8
Date:Tue, 05 Sep 2017 17:56:32 GMT
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Last-Modified:Tue, 05 Sep 2017 17:56:32 GMT
X-Content-Type-Options:nosniff
X-Drone-Version:0.7.3+build.1139
X-Frame-Options:DENY
X-Xss-Protection:1; mode=block

Request Headers
Accept:/
Accept-Encoding:gzip, deflate
Accept-Language:en,es;q=0.8
Connection:keep-alive
Content-Length:0
Cookie:user_sess=<
Host:drone.siplay.io:8000
Origin:http://drone.siplay.io:8000
Referer:<>
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
X-CSRF-TOKEN:<>

Body: Bad request

It looks like Bitbucket is rejecting the request. The only time I’ve seen this happen is why your server address is localhost / not publicly accessible by Bitbucket.

Note that when running Drone behind a load balancer or reverse proxy it will mask the real server address. When this happens drone will think that its address is localhost, and will therefore use localhost to construct the webhook URL. This can be solved by configuring your reverse proxy to set the appropriate X-Forwarded-For and X-Forwarded-Proto headers.

Also are you sure http://drone.siplay.io:8000 is publicly accessible so that Bitbucket can post webhooks to that address? I am unable to access the URL from my browser.

that’s not what this setting stand for: DRONE_HOST?

Bradry thanks for your help! yeah…what you found was that I was exposing the app through an internal Load balancer, and since I was testing inside my VPN didn’t realize that wasn’t public, I have changed that and I’m allowed to use it now. Another pair of eyes was really good!

Thanks again!

glad to hear you got it resolved.

yep, but the drone_host configuration parameter is brand new, and is being introduced into the codebase gradually. Eventually it should completely eliminate this class of problems :slight_smile: