Major/minor release for adding new domains to Forge Remote data residency regions

Forge Forge Modules and Product Triggers
,
1

I’m struggling to understand how the addition of a new domain name for a new data residency region in my manifest will be interpreted by Atlassian. I need to know if it will be considered “privilege escalation” or not, as this drives the differentiation between major/minor releases according to https://developer.atlassian.com/platform/forge/versions/#major-version-upgrades comment about the forge version bulk-upgrade tool.

This page https://developer.atlassian.com/platform/forge/remote/remote-realm-pinning/ says that “adding new regions” constitutes a major version release, despite the fact that the new region does not affect existing installations, unless the customer does a realm migration which is an explicit adoption of the new region and Forge Remote backend.

This page https://developer.atlassian.com/platform/forge/manifest-reference/remotes/#major-version-upgrades says that adding a new URL to an existing remote constitutes a major release, but does not document the categorisation of defining a new region using an existing URL that is already present in the manifest.

Have I interpretted this correctly, that adding any new region to the manifest is a major version release that cannot be targetted using the forge version bulk-upgrade mechanism? Even if the URL we use is the same as an existing region?

For clarity, I want to do this:

  remotes:
    - key: remote-backend
      baseUrl:
        default: "https://backend.example.com"
        US: "https://us.backend.example.com"
        EU: "https://eu.backend.example.com"
        DE: "https://de.backend.example.com" <-- new URL / hostname
      operations:
        - storage
        - fetch
        - compute
      storage:
        inScopeEUD: true

or this

  remotes:
    - key: remote-backend
      baseUrl:
        default: "https://backend.example.com"
        US: "https://us.backend.example.com"
        EU: "https://eu.backend.example.com"
        DE: "https://eu.backend.example.com" <-- existing URL / hostname
      operations:
        - storage
        - fetch
        - compute
      storage:
        inScopeEUD: true

but I want to avoid a major version release, unless I’ll be able to target it using forge version bulk-upgrade

2

Hi @jbevan,

Both are major. Tested today on a dev environment, forge cli 13.3.0, starting from:

remotes:
  - key: backend
    baseUrl:
      default: https://api.example.com
      EU: https://eu.example.com

Adding DE: https://eu.example.com gave a new major. Egress list unchanged.

AU on a brand new URL, same thing, major again, while a code-only deploy in between stayed a minor so the region key itself is the trigger and the reused URL doesn’t save you anything.

The cli doesn’t print “major” on deploy though. You see it in forge version list and the install going to “Outdated app”.

Bulk-upgrade does take it. Ran forge version bulk-upgrade start -e development --from-version 20 --to-version 21 --limit 1 from the default+EU major to the one adding DE (reused URL). Completed, install back to Up-to-date, no scope confirmation. Control: a major with an extra write:jira-work scope got refused, the cli calling it privilege escalation due to additional scopes. I’d read that as major but not escalation, at least in dev.

Didn’t try it in production or with a region on a brand new URL. And the cli exits 0 even when it refuses. A refused one never shows up in forge version bulk-upgrade list, so check for your upgrade there rather than trusting the exit code.

3

Thanks, I’m embarrassed that I didn’t think to just try it against a development environment too!

However, I just tried the following, one by one, which all created a new minor release:

  • new remote
  • enabling customer managed egress
  • new remote region with existing URL
  • new remote region with new URL
  • removing a remote
  • removing all regions for an existing remote

Which flatly contradicts https://developer.atlassian.com/platform/forge/versions/ and https://developer.atlassian.com/platform/forge/manifest-reference/remotes/ so I’m none the wiser… maybe I’ll just do it for real against production and see what happens :person_shrugging:

Edit: removing a permission scope does trigger a major version release :thinking:

4

Reran it in a brand-new dev environment with zero installs, forge CLI 13.3.0. Still majors. String to default plus EU, adding DE on the EU URL, adding AU with a new URL, all new majors, while an unchanged redeploy stayed minor.

After an install, adding US and then removing it were majors too. Install went to “Outdated app”.

forge deploy doesn’t print major or minor on 13.3.0. No MAJOR_VERSION_RULE warning either, at least in dev. The count in forge version list -e <env> --json is where it shows, and that lists majors only.

Not tested: customer-managed egress, a brand-new remote, removing a remote, removing all regions.

Where did you see minor, and on which CLI version? Before production I’d try a throwaway env from forge environments create.

5

I think it might be these rules at play Minor version updates (Connect to Forge) which contradict some of the ones I’ve already linked to…

6

Hi @jbevan,

Yes, that fits. The Connect to Forge updates page is scoped to “Subsequent updates of a Forge app that contains at least one Connect module”, and its table has “Addition of one or more new remotes” with no admin approval and no bulk upgrade.

The general remotes page says the opposite. Neither links the other. Our lab app is pure Forge, which would probably explain why we got majors and you got minors.

Not all of it though. The Connect table doesn’t cover adding regions to an existing remote, reused URL or new, or removing all regions, so those aren’t explained by anything I found. Customer-managed egress might fall under its fetch-permissions row, but that’s a stretch.

Does your manifest still carry connectModules or app.connect?