Pipeline deployments from Bitbucket cloud not being shown on Jira Cloud

[Roger Gros]

We use Jira and Bitbucket cloud for our daily work. For a while now we've been using pipelines to generate builds and deploy our project. We've integrated Bitbucket Cloud and Jira cloud as documented (At least we tried).

This integration works quite well. After some time working we can see Branches, Commits and Pull requests on Jira.

We can see the issues being deployed on Bitbucket Deployments.

But after a deployment is finished, no info is shown on Jira (first screnshoot). We've read on the documentation that a "release panel" should appear if you use Bitbucket pipeline, but we don't see this panel anywhere (View)

Is our integration miss-configured? Do we need to do anything special to enable this "Release panel" feature?

[Alkaid Llanes]

Is there an answer for this?

[Mikko Ylen]

I've been trying to get this working for a while as well. All the Jira issues, builds and deployments are linked and showing in Bitbucket but in Jira I only saw the Branches and commits. No deployment or build information was available.

Today it started to work with some of our repositories after I enabled Jira Labs from Personal Settings to get the new issue view to show up. Now I can see Build information on some of the tickets but not all. When I switch back to the old issue view the deployment information disappears. Might be some issues in syncing the data but not sure.

Not sure if it helps but there seems to be some difference if you have are using Jira core project or a Jira Software project as explained in Connect Jira Cloud to Bitbucket Cloud.

[Kathryn Kosey]

I too am searching for an answer to this... anyone have any updates?

I even tried updating adding to the default merge message to include exact tickets, but it still won't show in Jira issues.

[tom peacock]

I'm not with Atlassian but i think it's most likely something to do with your smart commits.

a task knows if it is part of a deployment by looking through the commit history that the deployment has access to and checks if it's ID (part of the smart commit) is included in the commit message. 

an example where this wouldn't work is merging develop into release where the message would be 'merge branch "develop" into release'. in this case develop may have a history of commit messages that include smart commit messages but the release branch won't. so pushing the release branch as a deployment won't register the task as being part of that deployment as the commit messages don't include smart commits.

I believe that's why pull requests through bitbucket (automatically) list the commits in the pull request commit message so that the new branch includes all the smart commit tags of the branch being merged. that means deployments have the list of all the smart commits being merged into the new branch and telling the deployment what tasks are part of it.

not 100% sure if that's the issue because you have blurred commits but that's an issue I've had. hope it helps.

[tom peacock]

disclaimer: i don't work for Atlassian... so im not exactly sure how they wire it all together...

i have a hunch that its all to do with the smart commits though.

could this be something to do with your commit history?

i say this because i noticed today that if i merged 1 branch into the other (develop into release) and deployed the release branch as a build, with the auto generated commit message being 'merge branch "develop" into release',  it wouldn't update the jira task with the release data because it didn't seem to have access to the commits from develop in the deployment commit summary. 

so the develop branch has a history of commits with 'smart commit' messages in them and by just merging them doesn't give release the history of commits, right?

something I've noticed with pull requests on bitbucket is that when you do this process (specifically through bitbucket) they generate a description with a list of all the new commit messages from that branch, including the smart commit messages. So in that case, after the pull request is merged with the message including a history of smart commits, and jira task IDs...  The release deployment will have access to the commit message of the 'merged pull request' which includes all the smart commits from the develop branch (auto generated by atlassian). 

TLDR;

i think a task is able to tell if they are part of that release or not by looking through the deployment commit history and seeing if its ID is included in any of the commit messages.

that's the theory anyway... hope it works!

[Jiří Žaloudek]

I have exactly the same problem, any hints?