Which Jira issue key reference approaches are currently supported by Develop with AWS for Jira?

Develop with AWS for Jira integrates your AWS DevOps toolchain with the Atlassian Open DevOps experiences in Jira – Jira supports 4 core approaches to Reference work items in your development projects | Jira Cloud | Atlassian Support:

Develop with AWS works event based, so just as with your Git integration for Jira, you need to push something to the connected repository to trigger a deployment/build (or do so manually) so that the AWS service event can be ingested to Jira (events usually surface in under one minute).

	CodePipeline	Notes

	CodePipeline	Notes
Branch name …
… before merge	supported	If this doesn’t yet work for you, we might need to deploy an update for your installation – contact us and we’ll get this sorted.
… after merge	conditional	This works if your Git tooling references the issue key in the branch name and in the subsequent merge commit message, which is e.g. the case for the default GitHub merge workflow and the default Bitbucket merge workflow.
Commit message …
… of last pushed commit	supported
… of all pushed commits	workaround	The CodePipeline events only include the last commit ID, so if a push contains multiple commits, we lack access to the resp. commit data (we are investigating how to eventually work around this via a CodeBuild action that uses a full clone to extract and forward this data)! Depending on your workflows, you might be able to leverage the following workarounds: You can manually include all issue keys in the PR description and ensure inclusion of the description in the subsequent merge commit message by https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-merging-for-pull-requests: ”The default message includes the pull request number and title. For example, `Merge pull request #123 from patch-1`. You can also choose to use just the pull request title, or the pull request title and description.” You can automatically include all issue keys in the PR description and ensure inclusion of the description in the subsequent squash commit message by https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests : ”The default message uses the commit title and message if the pull request contains only 1 commit, or the pull request title and list of commits if the pull request contains 2 or more commits. You can also choose to use just the pull request title, the pull request title and commit details, or the pull request title and description.”
Pull request title …
… before merge	unsupported	We do not have access to pull request data from the various upstream Git providers, so this seems blocked for now.
… after merge	conditional	This works if your Git tooling references the issue key in the pull request title and subsequent merge commit message, which is e.g. the case for the default GitHub merge workflow and the default Bitbucket merge workflow.