You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
To get issues to have associated/linked deployments, I am finding success by including the issue key in the commit message. However, the documentation leads me to believe that this should work based on branch name as well (which does appropriately link to the issue, but does not track along with the deployments).
When I use merge commits, and merge in a branch with the issue key, and keep that as the merge comment, then it tracks deployments appropriately (because the issue key from the branch name is now in the commit message history). Is this the only way to do it? The docs are a little unclear on this, and it's slightly unfortunate for the use case I have: PR-linked deployments from branches aren't showing in the Jira issue that they have been deployed to a given environment.
Are you referring to the Deployments tab, in the Development panel of a Jira Cloud issue?
If so, the deployment is indeed linked only if the commit associated with the deploy contains the issue key in its commit message. See the link below, in the section "Deployments":
A deployment to an environment, such as production or testing, is linked if a commit associated with the deploy contains the issue key in its commit message. The issue key must be included in the commit to activate this feature.
If the deployments run on a pull-requests definition in your bitbucket-pipelines.yml file, the issue key needs to be present in the last commit of the source branch.
What happens if the deployment is run from tag instead?
If I currently tag the commit and the deployment pipeline is executed, only that issue is now linked to the new deployment environment.
How can all other issues in the git tree between the current and previous deployment be linked as well?
A tag is associated with a certain commit, so when you run deployments from a tag, it's again a specific commit that is associated with the deployment.
What I mentioned in the previous post applies in that use case as well. The deployment is linked only if the commit associated with the deploy contains the issue key in its commit message.
Hi @Theodora Boudale, thanks for your responses, our team is struggling with this issue right now. From what you said, it sounds like it's only possible to link deployments to Jira issues only if you make that deployment from commit associated with certain issue.
In our workflow and in accordance with Atlassian Deployment Guidelines, we deploy from `main` branch. Once it's ready to be released, we trigger custom pipeline (from the latest state of `main`) and deploy to staging environment:
We noticed that only issues associated with the latest commit in `main` (JRA-3) have been linked to the new deployment. But before JRA-3 we have more issues merged (JRA-1, JRA-2). Does it means that these issues will not be linked to the latest deployment and not flagged as "Deployed to Staging"?
If I understand it correctly, it kind of ruins the idea of monitoring deployments from Jira: you will never know where code associated with certain issue was delivered to. Could you please let me know some way to associate previous issues with the latest deployment?
Thank you for reaching out.
Is your team pushing commits to main branch? If so, what you could do instead is the following:
When you merge a PR from our website and the source branch has more than one commits, then the commit messages of all these commits (including the Jira issue keys) are populated automatically in the message of the merge or squash commit.
The merge or squash commit in main branch will contain all Jira issue keys that were worked on my-feature-a. If you trigger a deployment pipeline for this specific commit, then the deployment will show in all associated Jira issues (in the Development panel).
If you are already following this strategy, and JRA-1, JRA-2, and JRA-3 are merge commits from other branches, you would need to trigger a deployment for each commit in order for the deployment to show in each Jira issue's Development panel.
One way to work around this would be by creating and pushing to main an empty commit
git commit --allow-empty -m "Empty commit for deployment JRA-1 JRA-2 JRA-3"
and then trigger a deployment for this empty commit.