Which Jira Software issue key reference approaches are currently supported by Develop with AWS (Jira)?

Develop with AWS (Jira) integrates your AWS DevOps toolchain with the Atlassian Open DevOps experiences in Jira – Jira Software supports 4 core approaches to https://support.atlassian.com/jira-software-cloud/docs/reference-issues-in-your-development-work/:

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 Software (events usually surface in under one minute).

	CodePipeline	Notes

	CodePipeline	Notes
Branch name	in the works	The CodePipeline events readily include the branch name so we can provide this capability soon.
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 (and description) …
… 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 … … either in the PR title and in the subsequent merge/squash commit message (e.g. the default GitHub merge workflow, where the title is used in the commit message, while the PR description is ignored unless changed in repository settings – see default GitHub squash workflow for an alternative) … or alternatively in the PR description and in the subsequent merge/squash commit message (e.g. default Bitbucket merge workflow, where the description is used in the commit message, while the PR title is ignored)