Update regarding the recent announcement for Connect in Bitbucket Cloud

Bitbucket Development Bitbucket Cloud
,
1

Hi everyone - I wanted to share some additional information and changes in response to the previous post regarding Connect in Bitbucket Cloud. This second post is a bit long, but the last thing we wanted to do was “under-bake” our response to everyone’s comments.

First, I want to acknowledge everyones input & feedback and thank everyone who contributed. There are several elements that we didn’t communicate effectively, and a few areas where we simply missed the mark and need to make changes.

Most importantly, I want to clarify that this is “the start of a conversation”, not “a final announcement”. We are clarifying some things and making a few changes - so please continue to engage with us, and we will share more information where needed and adjust our plans where appropriate.

There are a few things we’re sharing here:

  • A change in the timeline for “updates to existing apps”.
  • Clarity on what exactly is meant by “updates” in this context.
  • Info on Connect => Forge migration path for Bitbucket apps.
  • A commitment to “Parity-plus” between Forge and Connect in Bitbucket Cloud.
  • Our plan & commitment to improve this process moving forward
  • A quick note on Paid-via-Atlassian

Timeline for “updates to existing apps”:

  • Initially we stated that, starting in 3-months time, updates to existing Bitbucket Cloud Connect apps in the Marketplace will no longer be possible.
  • As an immediate change, the timeline for updates to existing apps is being extended to 6 months.
  • Additionally, any notice period regarding final end-of-support for existing apps will begin no earlier than August 2025, and run for a minimum of 6 months.
    • Final dates & notice periods will be heavily based on feedback & input from the community.
  • There is no change to the timeline as it affects new app listings (3 months).

Connect timeline
Connect timeline1920×413 32.5 KB

Note “Earliest possible”, may be later based on community feedback

What exactly is meant by “updates” in this context:

  • We didn’t clearly explain what was meant by “updates to existing apps”, which led to varied interpretations, including the (understandable) assumption that apps could effectively become “frozen”.
  • So, to be clear on what exactly is meant by “updates”:
    • Updates that require a change to the scopes defined in an app descriptor.
    • Updates that require a change to the modules defined in an app descriptor.
  • Partners will not be prevented from making updates that exist within the already defined scopes/modules of their app descriptors.
    • e.g content changes to existing UI modules, bug-fixes, etc.
  • Additionally, exceptions will be made for any updates that are designed to assist the partner in migrating that app to Forge, or assist the partner in migrating their existing users to a Forge-based equivalent.

Connect to Forge migration path:

  • A few questions were raised regarding incremental migration paths from Connect to Forge for Bitbucket apps.
  • Unfortunately, we can’t offer the exact same migration path as Jira & Confluence due to differences in the Bitbucket Cloud Connect implementation.
    • However, there are incremental migration steps available - most importantly, Forge Remote.
    • This means that your app does not need to be rewritten to run in a node.js environment in order to migrate to Forge.
  • Regarding migration of existing Marketplace listings & installs - we face a similar situation here.
    • However, we do want to try and find any opportunities we can to reduce the friction/burden of migrating customers to equivalent apps on Forge.
    • In line with this, we will commit to publishing an RFC to collect feedback/input from partners on potential ways to streamline this process within the next two weeks.
  • Additionally, where any specific friction-points are identified in terms of migrating application, we will make sure dedicated support content & guides are created to address those items.
    • Please let us know of any specific challenges you would like to see addressed.

“Parity-plus” between Forge and Connect:

Plan moving forward:

  • While this communication is not a final end-of-support announcement, we strongly recommend that partners begin exploring the migration from Connect to Forge as soon as possible.
  • We want to ensure the migration to Forge is a success, so we’ll be providing support and resources to facilitate a smooth transition via the Bitbucket Cloud space in Developer Community.
    • Please continue to post your questions, feedback, issues, etc so that we can identify what needs to be done and support you where needed.
  • As mentioned, we will publish an RFC in the Bitbucket Cloud space to gather partner input relating to migration friction points for existing app listings within the next two weeks.
  • Additionally, we’ll be reaching out to the vendors who’s apps account for the overwhelming majority of Connect installations in Bitbucket Cloud directly over the next few weeks to discuss how we can assist in making this transition as smooth as possible.

Paid-via-Atlassian for Bitbucket Apps (PvA):

  • Speaking personally for a moment, getting this done is particularly important to me.
  • I know that the lack of PvA is an ongoing point of frustration when it comes to Bitbucket apps.
  • It’s something I’ve personally said to many of you is coming and that has not changed at all - it’s just a lot of moving pieces.
  • Significant progress has been made towards this goal and we’re actively implementing the last major platform dependency standing between us and PvA for Bitbucket apps.
  • We’re not yet at a point where we can give specific dates, but material progress is absolutely being made. We will share timelines with the community the moment we are confident we can commit to them.

Wrapping up

Success for the Bitbucket ecosystem is defined by the success of our partners, and the Bitbucket team is more committed to achieving that today than it ever has been before.

Fundamentally, our goal is to create a consistent, predictable, stable, and “Atlassian standard” extensibility platform that you can all rely on to build your own businesses and serve our shared customers.

Thank you all for your input and for continuing to advocate to make the Bitbucket ecosystem the best it can be. Please share any thoughts, feedback, suggestions, or requests in the comments below.

8 Likes
2

Thanks @EdmundMunday !

I’m adding a couple of Bitbucket connect modules that have no equivalent in Bitbucket forge

  1. API Proxy : if there is a generic way in forge to build an app REST-API, perhaps link it to this page.
  2. Profile tab
  3. This is a wish-list item, or another sweet carrot if you will:
    bitbucket:repoSettingsMenuPage
    bitbucket:projectSettingsMenuPage
    bitbucket:workspaceSettingsMenuPage
    BBC has a project settings page, apps should have too!

Can you also please elaborate what checks are in place on Atlassian’s side, that need to be ticked before the next phase is enforced?

Thanks again for moderating this process.

2 Likes
3

Thanks @EdmundMunday

To second the comments from the other thread, our apps are using the File Viewer connect module which currently does not exist on Forge.

Can you share any information on when this feature would be available?

1 Like
4

Hey @UlrichKuhnhardtIzym1 - thanks for sharing those.

  1. Web Triggers can be used to create your own REST endpoints attached to a Forge app as you can define your own arbitrary HTTP response to be returned from the Web Trigger. The only limitation (that I’m aware of) is that all requests to a Web Trigger must be POST requests, so you can’t do “semantically correct” REST (e.g. POST, GET, etc) - you can absolutely achieve the same functional outcome though.
  2. Profile Tab - Yeah good call, I’m assuming the use-case you’re thinking about is allowing users to create their own “user-specific” settings for apps? What context (other than the details of the user in question + their Workspace) would you want to have available there?
  3. TBH we need to do a full pass of the Project level in regards to Forge, not just settings page. Settings should take priority though since the Project is mostly a configuration container.

In terms of what checks we need to pass before the next phase, my view is that we need to have a clearly documented, “production-ready” way to solve all the existing Connect use-cases before we consider any kind of “next steps”.

Now I do want to be clear, solving all the Connect use-cases does not necessarily mean providing all the exact-same features. API Proxy is an excellent example - I’m hoping there is a way we can solve that “use-case” in a way that is a bit more… conventional. I know it’s basically a meme that “every product includes a non-standardised, undocumented, totally proprietary equivalent of GraphQL” - but API Proxy takes that to a new level.

Would be great to get your feedback re: Web Triggers and whether you see them as a viable equivalent.

@JanNylund - thanks for sharing that! I can’t give you a specific timeline, but we will include this in the list of items that need to be delivered before we enter any next-phase of the process.

Could you share some info in terms of what context you’d like provided from the host app to be passed to that module? I’m assuming:

  • Repo, Project, Workspace context
  • Information about the file-path/name
  • Maybe latest commit hash??
  • Anything else?

FYI - I will be off on medical leave for the next 2 weeks, but will loop back to this thread when I return. @HamreetKaur will be making sure the mentioned RFC is published before then.

3 Likes
5

Hi @EdmundMunday and team,

REST API

Our app will aim for the “Runs on Altassian” badge. As per the Webtriggers and RoA chat web triggers must not return data if the app has the “RoA” badge. Other vendors have a similar use case.
If “RoA” enforces no data egress, Web triggers is no replacement for any REST API GET or equivalent.
If web-triggers had (optional?) Atlassian authentication though, returning data via web-triggers should not jeopardize “RoA”, because it would just be the same as forge/bridge?

Profile tab

Yes correct. Workzone provides digital signature approvals for PRs. The digital signature tokens are managed in the user’s profile settings page. It’s the best place to give the user a sense of ‘privacy’.

my signature
my signature1690×534 36 KB

We would definitely need some type of personal settings page for Workzone.

Project settings

I’m not sure I understand: Do you mean there is a committment to provide a project settings module for forge apps?

6

In connect we run on account context with repository scope. Not sure how they map to forge, but essentially we would need:

  • a filename / extension to trigger the possibility to enable or disable the file viewer (similar to how this works in connect. Preferably also the possiblity to have it enabled by default, as is possible in Bitbucket DC)
  • read access to the content so we can render it using our custom file viewer.
7

Hi everyone,

Thank you all for your valuable feedback! We acknowledge that some comments are still unanswered, and we will be addressing them soon. In the meantime, I’ve just posted the RFC and would love to hear your thoughts on it. Your input will help us align and collaborate effectively on the migration journey. Looking forward to your feedback.

1 Like