Auth0 Home Blog Docs

Second tenant incorrectly processes Bitbucket Deployment

I’m trying to use Bitbucket Deployment to serve multiple tenants. We have a primary paid tenant for Production, and a secondary free tenant for non-production environments to share. I’m just setting all this up now for the first time (we are new customers.)

I have configured the primary production tenant to deploy from the master branch of our Bitbucket repository, and the non-production tenant to use another branch. The plan is to bubble up configuration changes first to the non-production branch, then to production.

Through trial-and-error I created an application record under clients/my-application.json that looks a little like this:

{
    "name": "My Application",
    "description": "Our application.",
    "logo_uri": "https://www.oursite.com/favicon.ico",
    "callbacks": [
        "https://www.oursite.com/auth/callback"
    ],
    "allowed_logout_urls": [
        "https://www.oursite.com/"
    ],
    "token_endpoint_auth_method": "client_secret_post",
    "app_type": "regular_web",
    "oidc_conformant": true
}

The problem

The problem is that while both tenants can “deploy” from Bitbucket successfully, only the primary production tenant will actually create and update the client application. The secondary tenant completely ignores it (even though the branch it’s configured to use definitely has that file.) It creates and updates no application.

Not sure where to begin.

If you haven’t done so already you should start by installing the Webtask Real-time Logs extension and then have this extension running while a BitBucket deployment runs. This will allow you to capture log information from the deployment extension and may provide you some additional data for troubleshooting purposes.

The most interesting tenant where to run the test would be the one that fails to create the application, but it may also be worthwhile to execute the test in the production tenant and then compare the output to see if there’s any obvious difference that could help pinpoint the source of the issue.

From misbehaving tenant:

9:23:59 AM:

new webtask request

9:24:05 AM:

2019-07-29T13:24:05.029Z - e[34mdebuge[39m: Files in tree: []

9:24:05 AM:

2019-07-29T13:24:05.041Z - e[32minfoe[39m: Getting access token for wUB***REDACTED***GDOE/mycompany-dev.auth0.com

9:24:05 AM:

finished webtask request

9:24:05 AM:

2019-07-29T13:24:05.467Z - e[32minfoe[39m: POST /2d3***REDACTED***7a/api/deployments 200 5628.025 ms - 191

9:24:05 AM:

new webtask request

9:24:05 AM:

finished webtask request

9:24:05 AM:

2019-07-29T13:24:05.586Z - e[32minfoe[39m: GET /2d3***REDACTED***7a/api/deployments 200 15.036 ms - 1311

From original (correctly working) tenant:

9:29:34 AM:

new webtask request

9:29:36 AM:

2019-07-29T13:29:36.305Z - e[32minfoe[39m: Starting Bitbucket Deploy extension - Version: 2.10.0

9:29:37 AM:

2019-07-29T13:29:37.516Z - e[34mdebuge[39m: Files in tree: [ { “path”: “clients/mycompany-application.json”, “sha”: “clients/mycompany-application.json” } ]

9:29:37 AM:

2019-07-29T13:29:37.929Z - e[32minfoe[39m: Getting access token for o***REDACTED***l0/mycompany.auth0.com

9:29:38 AM:

2019-07-29T13:29:38.175Z - e[32minfoe[39m: Updated [clients]: {“name”:“MyCompany Application”,“client_id”:“T***REDACTED***l”}

9:29:38 AM:

finished webtask request

9:29:38 AM:

2019-07-29T13:29:38.658Z - e[32minfoe[39m: POST /***REDACTED***a/api/deployments 200 2320.167 ms - 220

9:29:38 AM:

new webtask request

9:29:38 AM:

finished webtask request

9:29:38 AM:

2019-07-29T13:29:38.786Z - e[32minfoe[39m: GET /2d***REDACTED***7a/api/deployments 200 8.421 ms - 4191

Thanks, the interesting parts are:

Files in tree: []

and

Files in tree: [ { “path”: “clients/mycompany-application.json”, “sha”: “clients/mycompany-application.json” } ]

The above means that in the failing tenant the extension is not finding any files so the problem is not related to any issue in the creation attempt. It’s that from the perspective of the extension there are no files.

You should try to add other entity types in the failing tenant, for example a rule, and see if any of the other entities are created. If it continues to report no files in the tree then I would double-check and redo all configuration.

We ended up going with Deploy CLI - got it working in a few hours - works beautifully and we have more flexibility with multi-tenant configuration. Feel free to post other ideas about getting the Bitbucket Deployment to work, for future answer seekers.