Adopting Forge from Connect - which "connect specific code" should be left inside manifest after the complete rewrite from Connect to Forge?

Forge
1

Hello,

a little advice appreciated on this specific nuance.

Which “connect specific code” should be left inside manifest.yml after all of the connect modules have been rewritten into forge modules?

The manifest file - after a successful rewrite might look like this one.

app:
  id: ari:cloud:ecosystem::app/id
  connect:
    key: my.app.key
    remote: connect
    authentication: jwt
  runtime:
    name: nodejs24.x
  licensing:
    enabled: true
remotes:
  - key: connect
    baseUrl: https://connect-remote-com
modules:
  connectToForgeMigration:
    - key: apps-forge-migration-declaration
      migrationGuideUrl: https://www.example.com
      willMigrateToForgeBeforeEOS: YES
  function:
    - key: resolver
      handler: index.handler
  jira:projectPage:
    - key: app-project-key
      resource: main
      title: App Title
      resolver:
        function: resolver
  jira:globalPage:
    - key: app-global-key
      resource: main
      title: App Title
      resolver:
        function: resolver
resources:
  - key: main
    path: build
connectModules:
  jira:lifecycle:
    - key: lifecycle-events
      installed: /api/lifecycle/installed
      uninstalled: /api/lifecycle/uninstalled
permissions:
  scopes:
    - read:connect-jira
    - write:connect-jira
    - read:jira-user
    - read:jira-work

I am interested in particular in those options, if they can be simply removed

  • app.connect.key
  • app.connect.remote
  • app.connect.auth
  • remotes.connect
  • modules.connectToForgeMigration
  • connectModules.jira:lifecycle
  • permissions:*:connect-jira

I am sure the app.connect.key must stay - but I am not sure about others - at which point in time or if they can be removed at all

2

Hi,

During our adoption, in order for app to be treated as completely on Forge we had to do the following things:

  • The connectModules has to be gone completely - this includes the lifecycle events (We replaced them with Forge ones)
  • Any scopes that have the word connect in them have to be replaced with OAuth2 Scopes - Permission Mapping Table
    • Note: This will trigger a major update - if permissions are not elevated customers can be upgraded via the bulk upgrade command
  • From the app.connect key we had to remove the remote and auth options - key has to stay so our app can be correctly upgraded
  • We also removed remotes.connect but I’m not completely sure if it is required to do so
  • Regarding connectToForgeMigration I am unsure as this was not yet an option during our migration

I hope this helps to make your migration smoother. Happy to answer any other questions.

Best,

Aljaz

3

@Aljaz thanks for your quick reply!

I am also interested, if there is some kind of “official statement” from Atlassian stating that if “X” happens, then a connect app is no longer considered “connect”, but rather “this is forge app from now on”.

Since on the platform there will be warning messages shown for customers about phasing out of the connect platform - so how it can be made sure that for an app that was migrated (mentioned blocks of code removed) those warning won’t show up.

4

It was only May 26th that they first informed partners in a buried thread reply that they would be plastering warning messages on apps 3-6 months before EOS. And that was only first discovered by partners because they pushed it to prod without any warning.

5

There’s some new tooling available which might help answer your questions - Checking your Forge adoption status

6
  • 24 July: warning messages on apps are displayed to admins in prod
  • 30 July: adoption-status deployed publicly for @atlassian/connect-to-forge

If you’re still actively developing the tooling and documentation for Forge migrations, perhaps that should indicate that it’s far too early to be plastering warning messages on Connect apps.

8

@HeyJoe exactly what I’ve been looking for!