Hi @christian.ott,
I’ve done a bit of digging into your connect app. It looks like the lion-share (8504 out of 8611)
of installations still have a webhooks module in their descriptor. It looks like your original descriptors had the webhooks module defined, subscribing to all webhook events we publish. This explains why you have so much traffic coming to your webhooks endpoint.
From what I can see you’ve got 23 different “versions” of your descriptor floating around all with installations. Unfortunately when you push a new version of your descriptor, the existing installations of the older versions do not upgrade. New installations of your app will use whatever is the current “version” served by your descriptor url.
The good news is you should be able to update every old installation. We have an API which you (as the app vendor) are able to call for each installation, which allows you to upgrade installations to the latest served version of your app descriptor. Note that this endpoint only enables you to push changes which don’t require an increase in scopes.
To authenticate this request you craft a JWT token for the installation you wish to update. Unfortunately this means you’re required to make 1 call to update each installation.
https://developer.atlassian.com/cloud/bitbucket/rest/api-group-addon/#api-addon-put
Alternatively, we offer a different connect app model, called shared connect apps.
Shared Connect Apps vs Regular Connect Apps
This is not a well documented feature unfortunately (Getting started with Forge is the only place we talk about it), but It definitely is an improvement over the regular connect app model. For you it’d be useful for one of it’s key features; it allows you as app developers to push a new update of your app to all installations with the singular press of a button.
If you’re not increasing scopes, this change is instantaneous, and will update all installations in place.
If you have increased scopes the workspace admin for each workspace which has your app installed will receive an email stating that the app has been updated and the workspace admin has to consent the increase of scopes for the application.
Another advantage to the Shared connect application is that you have a singular secret shared all installations (hence the name) which saves having to store each installations unique secret.
The downside to this, is that once you’ve released a regular connect app out in the wild, it’s very hard to swap models to the Shared Connect App model. This is because the registration of the shared app requires that no installations using that key currently exist.
How to register a shared connect app
If you’re interested in using the shared app model, you’d probably need to register your app with a new app key which would mean producing a separate descriptor file.
- Go to your companies workspace and under workspace settings go to the
Develop App page under the APPS AND FEATURES heading
- Add the public url you expose for your descriptor file
- Once you’ve added this you should get a nice listing and a nice installation URL.
]
You then use the installation URL to install the application in workspaces (your personal workspace, or even your organisation workspace). This registration process is a once-off task, and basically ties the app you’re developing to your workspace to allow you to perform the administrative tasks etc.
Please note, Registering a shared connect app doesn’t install the shared connect app. You still need to install it into your workspace if you wish to test it etc
The Manage Apps page stores the secret for your shared connect app so you can retrieve them to auth your requests back to Bitbucket from your server. The update button allows you to push updates to the current installations, it does this by re-retrieve the descriptor from the descriptor URL you setup when you registered the app. It first validates the descriptor and then updates the installations. The remove button will remove all installations and de-register the shared connect app.
Hope this helps,
@DanFraser
