Forge deploy failing with remote baseUrl depending on env variables (Forge CLI 13.3)

Forge Forge UI Kit and Custom UI
1

Since Forge CLI 13.3 running forge deploy with that in manifest:

environment:
  variables:
    - REMOTE_APP_URL

remotes:
  - key: forge-remote
    baseUrl: '${REMOTE_APP_URL}'
    operations:
      - compute
      - fetch

Error message is

Error: The deploy failed due to errors in the app code. Fix the errors before rerunning forge deploy, or run forge deploy --no-verify to skip the linter.
.../manifest.yml
0:0 error Upsert Environment Request body is invalid.
Error message: baseUrl must start with http(s)
MANIFEST_INVALID_RULE

Both shell and forge env variables are not working.

2

We’re hitting the same regression since 13.3.0 — confirming you’re not alone, with a slightly different symptom: for us the deploy fails server-side with

Upsert Environment Request body is invalid. Error message: Invalid URL detected for EGRESS permissions object: ${LAMBDA_BASE_URL} MANIFEST_INVALID_RULE

for a manifest that’s been unchanged and deploying fine for months:

environment:
variables:

  • LAMBDA_BASE_URL
    remotes:
  • key: lambda
    baseUrl: ${LAMBDA_BASE_URL}

We A/B-tested it: identical manifest, identical environment, variable verifiably present in the process environment (per the manifest variables docs (https://developer.atlassian.com/platform/forge/manifest-reference/variables/)) — 13.2.0 deploys successfully, 13.3.0 fails, both locally and in CI. So it looks like the new pre-deployment validation introduced in 13.3.0 runs against the manifest before variable substitution, in both the client-side lint (your “baseUrl must start with http(s)”) and the server-side egress rule (our error).

Would be great to get confirmation from Atlassian whether this is intentional, and if not, a fix ETA — environment-specific remote baseUrls per Forge environment are a pretty common setup.

3

Hi there,

Thanks for reporting the issue. We are aware of a bug that was included in the new linter logic, which does not support the manifest environment variable interpolation.

This bug has been fixed but requires a Forge CLI release, which is planned for the 17th August.

In the meantime, feel free to either: downgrade the CLI version or run the deployment with --no-verify to bypass the linter.

We’ve also created this public bug ticket to properly track it: https://jira.atlassian.com/browse/ECO-1694

Thanks,
Xavier Caron

4

If any subset of devs can’t successfully forge deploy I would classify that a major bug even if there is a workaround. Any PaaS would too.

Bundling feature or non-blocking bugfix releases on a scheduled interval makes sense. Delaying major bugfix releases to match that schedule is poor software practice. Please do a CLI release immediately.

5

Wait, so Atlassian is asking ALL marketplace partners, representing a billion dollar industry, to spent time updating CI scripts to ensure continued operations just so that it can wait 10 days with a release?

In addition, ALL marketplace partners are also required to revert that change once the fix is available.

Either the Forge CLI release process is messed up, or Atlassian is still utterly and completely unaware of the size of the marketplace and is still treating Forge like it’s a 2019 hobby project

cc: @HeyJoe (for lack of clarity on team membership & hierarchy within Atlassian and hoping that this is an appropriate tag)

6

Hi there,

Thank you for your feedback. The bug has been mitigated as of yesterday.
Let us know if you are facing new or other issues.

Cheers,
Xavier Caron

7

@XavierCaron

thanks for the update on this.

is it fixed in 13.3 Forge CLI?

8

Correct, we have mitigated the issue for Forge CLI v13.3.0

And the next version of the CLI will have the longer term fix. But as of today, it is safe to switch back to CLI v13.3.0 :+1:

Hope this clarifies thing.

Cheers,
Xavier Caron

9

Wow, that seems strange to have two versions of Forge CLI with the same version number.

Couldn’t Atlassian just publish v13.3.1 as a patch release?

10

I assume it was a server-side fix.