Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Linking deployments of release branches to Jira tasks

What I want to achieve is tracking to which environment a jira issue is deployed.

This works fine when I always deploy from the same branch in Git, but is not working when I deploy starting from a branch.

Let me explain with an example:

  1. I create a task, I work on it and I commit.
  2. Bamboo build automatically and deploys automatically, and that build, which contains a commit linked to the task, shows it contains the task.
  3. If I "promote" the same build also to test, then that release on TEST will show all the new jira tasks since the last time something was deployed on TEST.
  4. Now I want to deploy to Staging. And for this I create a release branch, and I deploy to staging. Being this the first deploy coming from this branch, it doesn't show any task as included in the release. While it should.

Is this a bug of the Jira-Bamboo plugin? A misconfiguration of the plugin? or a missing feature?



3 answers

4 votes
Marcin Oles Atlassian Team Mar 14, 2019

Hi @Simone Chiaretta,

In current shape, Bamboo does not support comparison of two versions created from different plan branches. This problem also affects two versions deployed on a single environment.

This is due to the way how Bamboo calculates the diff (in commits, in Jira issues, etc.). We rely on partial diffs from build result history.

Each build result introduces a chunk of the diff (1 commit, 1 issue, for example). If we want to compare builds 1 and 10, we just add up all the changes. And since each deployment version must be based on some build result, it's possible to tell how many build results happened in between two versions, and hence it's possible to calculate the diff.

For two separate plan branches, we are not able to calculate the diff in the way it's done now, as they are divergent (no common ancestor in Bamboo build history). So if you create two deployment versions from build results which are not from the same plan branch, Bamboo can't calculate the diff for you.

However, we're open to accepting improvement requests. One possible improvement request could be for Bamboo to calculate diff based on e.g. the Git log, and to stop relying on in-between build results. You can create the improvement under

On another note: maintaining a single release brach may be an option for you, if you would like to workaround the problem. If you'd like to use the Git workflow, to my understanding, it assumes that there's a `master` branch which contains all the releases. (The ad-hoc release branches are ephemeral, after all.) Maybe this would help you.

Marcin Oleś
Bamboo dev team

1 vote

Hi @Simone Chiaretta

This is expected behavior, it happens because the deployment list of contents is created based on a difference between the last deployment and the current one for the same branch. If there is no prior deployment for that branch, Bamboo won't be able to know what commits and tasks are part of that release. 

The same behavior can be observed for plan builds. The first build of a branch will not list the commits or tasks due to the same reason. It needs to know what was part of the previous build to be able to list what is part of the latest one.

I've created the following feature request to report your need for this: [BAM-20341] First deployment of a branch should list commits and Jira linked content.

Please let me know If that makes sense to you.

Thank you for the answer @Daniel Santos .

It seems strange to see this behaviour since Atlassian recommendation is to use gitflow, which dictates that production releases are done from an ad-hoc release branch.

What workaround would you suggest so that jira tasks are linked correctly to release that come from a release branch?



I'll work on getting someone from Bamboo design to answer this one. The Bamboo devs are located in Gdansk and will only be able to help us tomorrow. In the meantime, I'll share what my understanding is.

You may have a release branch where you can run all your builds and iterate over it when testing each new feature added, but when the whole content of a release is added and tested you are able to merge it into a master branch or a platform branch which will be the one deployed. Using this approach you would have just a few branches that would be handling the stable version of your application. Those are the branches you will deploy often, therefore avoiding the issue mentioned.

Does it make sense to you?

Like Steffen Opel _Utoolity_ likes this

Hi @Simone Chiaretta

I'm chatting with a developer about your request and I want to check with you if the feature you think is missing is:

  • the comparison between deployments of different branches
  • the history of all changes since the branch was created (assuming there is no deployment for that branch before)

Can you confirm that for us?

Like Steffen Opel _Utoolity_ likes this

Is comparisons between deployment on the same environment, regardless of from which branch they came from.. so more or less your first option.

@Daniel Santos , so you suggest that I should keep a "permanent" release branch, to which I merge commits from develop?

As I shared before and @Marcin Oles confirmed in his answer below, you should use the release branches ephemerally. Deploying from a master or any other permanent branch of your choice would solve the issue. So once your release is done you can merge it to a permanent branch and deploy from it.

I voted on @Marcin Oles question to make the life of other users coming to this question a little easier. Please share your remaining questions on that thread.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events