This changelog is the source of truth for all changes to the Forge platform that affect people developing Forge apps.
See what's next for Forge on our platform roadmap.
We're excited to share that Forge, our app development platform for Atlassian cloud products, is now generally available. You can rely on Forge's hosted infrastructure, storage, and FaaS functions to support apps in production; all of which are backed by Atlassian's operational readiness. Learn more about building the next Marketplace hit with Forge.
Note that some functionality in Forge remains in beta while we're still making changes that may break your apps. Learn more about the current functionality in beta.
We have increased the default timeout for forge functions used in both the webtrigger
and scheduledTrigger
modules from 25 seconds to 55 seconds. Additionally, developers can now specify a timeoutSeconds
value for functions used in the scheduledTrigger
module, with a maximum limit of 900 seconds.
For more details, visit Platform quotas and limits
The short options -v1
and -v2
of the forge version compare
have been removed in major release v12.0.0 of the Forge CLI. Instead, you should use the existing long options --version1
and --version2
.
For example:forge version compare --version1=3 --version2=5
We have made this change to align with established CLI conventions around short options being single characters.
Run npm install -g @forge/cli@latest
on the command line to install the latest version of @forge/cli
and receive these changes.
See the forge version compare documentation for more information.
We’ve updated the minimum compatible Node.js version for the Forge CLI to 20.0.0. Developers running older versions of Node.js will need to upgrade to continue using the Forge CLI. This change ensures that all developers have access to the latest features, security updates, and performance improvements.
We've released a new major version of @forge/events for Async events API. This update includes changes to both event publishing, event consumption, job progress tracking and job cancellation, designed to improve the developer experience and prepare for upcoming feature additions. We describe the differences between major versions 1 and 2 in the migration guide.
This release includes the following changes:
Event publishing
The signature of Queue.push() has changed, with the parameter type PushEvent
now containing body
and delayInSeconds
. The event body
must be an object
.
Event consumption
Forge resolvers are no longer used. The Consumer module instead requires a Function.
Consumer functions are invoked with an AsyncEvent
, which contains the fields of PushEvent
as well as invocation-specific fields, including jobId
and retryContext
. jobId
is no longer available via context
. retryContext
and is no longer added to the event body.
Job progress tracking
JobProgress.getStats()
now returns a JobStats
object containing success
, inProgress
and failed
, instead of an APIResponse
.
Job cancellation
JobProgress.cancel()
no longer returns an APIResponse
.
We’re introducing the ability for apps to publish events, allowing for enhanced interoperability between apps. This feature enables apps to subscribe to events using the existing https://developer.atlassian.com/platform/forge/manifest-reference/modules/trigger/ module, opening up new possibilities for app interactions.
Developers can start using app events by implementing the https://developer.atlassian.com/platform/forge/manifest-reference/modules/event/ module in their apps. For detailed guidance and examples, refer to https://developer.atlassian.com/platform/forge/events-reference/app-events/.
To publish events using the runtime API, you need at least version 2.0.0
of the @forge/events
dependency. Add this to your package.json
:
1
2
3
4
5
{
"dependencies": {
"@forge/events": "^2.0.0"
}
}
We have introduced a basic ability for consumers of async events to control the rate at which events are consumed by setting a limit of how many events can be processed concurrently for an app-defined key.
These changes apply only to async events pushed using @forge/events
with major version 2.
Example usage
1
2
3
4
5
6
7
await queue.push({
body: { ... },
concurrency: {
key: 'my-key',
limit: 1
}
});
A new getUrl
method has been added to router
in @forge/bridge
. The method will accept a NavigationLocation
object and return a URL object for the corresponding destination.
This method is in Preview. For more details, see the router documentation.
Run npm install --save @forge/bridge@latest
in your resource directory to install the latest version of Forge bridge.
Forge apps can now impersonate any user from their context. This includes impersonating other users given a user ID, and impersonating users when no user is in session, such as from a scheduled trigger or product event listener. Apps will need to declare properties on their existing scopes to be able to do this. See https://developer.atlassian.com/platform/forge/apis-reference/fetch-api-product.requestjira/ for more details on how to use this on Forge functions, and https://developer.atlassian.com/platform/forge/remote/calling-product-apis/ for more details on how to use this on Forge remotes.
We have published a new migration guide to assist you in transitioning your Forge custom fields to use the isInline
property.
The guide includes two practical examples:
Migrating a Forge custom field to render inline
Migrating a Forge custom field to render in a modal
For more details, please refer to https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field/#inline-edit-migration-guide
The list of modified fields in the Jira workflow validator has been expanded to include two new fields:
Linked Issues
Comment
For a complete list of all supported field types, please refer to the documentation: Jira Workflow Validator.
We've added an openOnInsert
parameter for macros with classic configuration. This parameter allows you to control whether the configuration panel is automatically opened on macro insert, enhancing the user experience by providing more flexibility.
To use this feature, you must be on the latest @forge/cli
version 11.6.0
. For more information, see the macro module documentation.
We’ve added the ability to see insights into rate limits faced by your app into the developer console.
The new Rate limited
label will be shown in the usual error metrics tab of the developer console.
This rate limited error report only covers invocation rate limits that effectively prevent your app from running.
This is aligned with the invocation rate limits we have documented.
We’ve added a new command, forge build
, to the Forge CLI that lets you bundle and upload builds of your Forge app without deploying them to a specific environment. This command includes the subcommand forge build list
to list out the builds for your app.
Builds are environment-agnostic and can deploy to any environment. Each build is assigned a unique and immutable build tag, which can then be passed to the forge deploy
command to deploy the build referenced by the tag.
With forge build
, you can now:
Deploy the same build across multiple environments without needing to re-bundle and upload source code
Rollback a deployment in an environment by re-deploying an older build.
Run npm install -g @forge/cli@latest
on the command line to install the latest version of @forge/cli
and receive these changes.
forge deploy
without a build tag will continue to function as normal and will not create and store a re-usable app build
Builds not actively deployed will be retained for a minimum of 30 days, after which they may be cleaned up.
Example Usage
You can create a new build for your app by running:
1
forge build
which will bundle and upload a build of your app and return a system-generated build tag. Alternatively, you can pass in --tag
to specify a custom tag. For example:
1
forge build --tag my-tag
You can then deploy this build by running:
1
forge deploy --tag my-tag
In partnership with Vanta, Atlassian conducted an analysis to determine how we can make it easier for developers to meet SOC 2 requirements. Apps built on the Forge developer platform can benefit from inheriting controls to meet 30% of SOC 2 requirements.
For more information, see https://developer.atlassian.com/platform/forge/forge-and-soc2/
Blob objects can now be sent and received via the events API. This enhancement allows for more efficient data handling and transmission within the API.
Update to the latest version of @forge/bridge
with npm install --save @forge/bridge@latest
Rate this page: