7036bc724bf2 Our plan is for the release to go public within the next 2 weeks.

Excellent, a fix for this will be very welcome! This hits us quite a lot.

Do you have a rough eta?

Thanks,

Rob

The problem is going to be fixed in Bamboo 6.10.

Please note however, that the fix only applies to branches that are actually removed from vcs and then re-created.

The fix does not apply to the plan branches that are removed due to inactivity, as this is completely different and more complex problem: re-activating inactive branches requires tracking activity of those branches. If there are lots of branches in the vcs system the performance ramifications are huge.
We will consider solving the problem of inactive branches reactivation in the future; please follow this ticket: BAM-20608

I think this is a serious bug. I have just experienced it with a couple of our Build Plan Branches - Release branches for which we lost history;/

The cleanup task should ALWAYS check if Bitbucket branch exists in case the cleanup was trigger by deletion, not inactivity.

Version: 6.7.1 build 60705 - 18 Oct 18

Scenario:

Day 1:

• Create new branch 'X' in Bitbucket
• 'X' gets created automatically in Bamboo Build Plan
• 'X' gets deleted manually in Bitbucket due to mistake
• 'X' gets created again from proper hash
• Bamboo Build Plan Branch 'X' is re-enabled manually
• Couple of other branches (before 'X-1' are renamed to be 'X' and point to the Bitbucket branch - they have never been mare as deleted)

Day 2:

• All branches are gone in Bamboo (we have setting to clean them after zero days)

This is an annoying bug for us as well. As all member (dev's) don't have edit permission for plan and need to create a ticket for us.

I really want to see this fix in upcoming releases. 

We are also hitting this.  What's the process for getting attention on this issue?  It's marked as priority "Low" and has 175 votes.  It's been an open issue for almost 7 years and has about 35 comments from people begging to get it fixed/implemented.  It's obviously in the portion of the backlog that just sits there, so how can we get it to be noticed and worked on?  Is there something specific like "votes" that gets it on someone's radar at Atlassian?

Agreed with all the previous comments saying it should be treated as a BUG.
It's getting ridiculous that this is still not fixed.

The workaround for adding branches manually is kind of silly. Especially when you have people who don't have edit plan permissions and their branch is missing. They have to create a ticket to the team that has those permissions so that they can add the branch for them. 

Please change the priority from "low" to  "ASAP"...

I have also just run into this problem.

Pushed new branch, build kicked off, merged PR in Bitbucket and checked the box to delete the branch.

A few days later we needed to make a change. The branch was re-created with the same name, pushed, build did not kick off. Bitbucket refuses to allow merge because there are no successful builds.

This is very annoying.

I've voted for this because this is a major requirement for working with build branches. Effectively, lack of this feature makes automatic branches management totally useless. And moreover, it makes Bamboo Specs useless, because those who would like to run builds on custom branches, do not have permissions to change Bamboo Specs for the build plan (and they don't have expertise for this), as well as Bamboo Specs plan would be a huge mess with hundreds of branches specified there.

I've spent countless hours fielding developer complaints that their branch isn't showing up or continuously is deleted even though it has been recreate manually (when auto-delete is enabled).  This is a frustrating issue.

Agreed with all of the comments here and how is this not viewed as a bug that's high priority? It results in very surprising problems that waste developer time and make Bamboo an inferior product to other CI offerings on the market.

This should be a BUG instead of Improvement/Sugestion as the branch is recreated it should trigger the plan branch creation in bamboo.

This is causing unecessary work to create the branch manually. It shouldn't care if the branch already existed in the past. 

Thank you.

My requirement is to run CI on all branches which has code commits in the last 24hrs.
Request you to resolve this issue at the earliest.

Please fix this in the next release, because it is very annoying that you have to be an admin to re-create the plan branch, and that is not a task that should be performed every time this happens.
Any workarounds?

I think this is not an "Improvement", this is a bug.

The problem is not that the plans are not recreated.

The problem is: If you recreate it manually, the plan branch is removed automatically with the "Daily cleanup configured"

We would like to have this feature implemented as soon as possible too. 

I would like to know a few things here about the current behavior of plan branches in bamboo for latest version.
1) With auto branch enabled setting, if someone manually deletes the plan branch and re-creates it within the plan , will that be automatically cleaned up by bamboo in sometime. Please note the corresponding Bitbucket branch is still intact and nothing has been done there.

2) Every time that one does as mentioned above, i believe a new branch-id is created for the plan branch even if the Bitbucket branch is the same and has been there ever. Having said so, does bamboo just look after the branch details in accordance with the Bitbucket repository like detected_deletion_date, etc or how is it recorded within bamboo database.

3) With auto branch setting after a certain period of inactivity, the branches automatically gets cleaned up from the plan, and for any later commits to the branch we have to manually re-add the branch in the plan for the builds to work. I wonder if these branches again get auto cleaned up next time that bamboo does a auto clean activity or they remain active in the plan as long as their corresponding Bitbucket branches have some level of activity going on.

All these questions are to address how bamboo tracks the plan branches. Because as long as the branch in Bitbucket has not changed/deleted, the plan branches don't have any detection_deletion_date and if they are manually deleted or get deleted and re-added as per #3, how does bamboo then track those branches.Does bamboo still refer to old deletion date or how everything works.

Any help here would be greatly appreciated.

Cheers,

Ashley

Even worse:

I found out recently that the once deleted branches get deleted again at daily cleanup - even if i manually re-create them.

If you are close to that time (like happened to me), you have a successful-email build with artifacts. And when you look for it an hour later, its gone.

I'll also chime in and say it affects our workflow as well.  The behavior is not intuitive so also believe it belongs in the bug category.

This is a bug, not an "Improvement". This breaks development workflow. Please fix this.

@Mattew Vines: Thanks for your reply.

This is what we are doing as a workaround now.

@Saifuddin We have had to work around this.  The basic rule is that you can add commits to a branch until it is merged.  Then you need to create a new branch.  So if you had a PR for branch AB-123, you can add commits to it while the PR is open without causing problems in Bamboo.  But as soon as AB-123 is merged back into Development.  Any further changes required on that branch need to be made in a new Branch.  Our convention is along the lines of AB-123-2, then AB-123-3, etc. but any new branch name will work.

Is there any updates on this improvement ticket?

This is hurting us in our workflow and the workaround suggested by Tyler is risky.

It looks like all the other open issues related to this issue have been resolved. Is there any update on if this will be added to a new release soon?

Very weird that you can't get the git commiter timestamp for the latest commit in a branch. Somewhere some component is looking at a git repository and seeing the branches and commits, which means having access to this timestamp.
If you do have this timestamp, seems the logic for revival would be straightforward.

+1

It should be noted that Tyler Walters workaround requires elevated permissions. At my company, only a couple developers have branch tab access in the build configuration.

Please add Tyler Walters workaround description to the bug description text. That makes it easier to find. Thanks.

This is a bug and not an improvement!

There are a couple other options we could have that don't involve changing the automated behavior of Bamboo. I should be able to manually add a build plan for a branch. Or when I run a custom plan based on a revision. If that is the head revision of a PR, count it for the successful build in Stash. Either one of those would easily clear the block this creates.

This is still an issue and is quite disruptive to developments that use the build numbers in the version of their products. If a branch is removed and then recreated manually (the current workaround) the build number is reset to 0. This gives rise to conflicts in our software library as it tries to create duplicates, which is not allowed.

My use case is slightly different. following a pull request in stash, developers quite often delete a branch as the work is considered finished. but in some cases a follow up change is required. Meaning the branch is pushed back to the repo by another developer. In this case, bamboo creates a new plan branch even if the previous one has not yet been cleaned away.

In my opinion, if a plan branch is cleared away, then you should expect a bit of extra work to get it back. But if the plan branch is already in existence on bamboo, the auto detection process should identify the existing plan branch (matching branch names?) and update the cache rather than create a brand new plan branch.

An even bigger problem is that if I have to manually re-add a branch plan after is has been removed for inactivty, the build number is reset to one. Then I have to kick of n throwaway builds to get the build number back to where it was. It would be a big help if bamboo could at least set the build number back where it was when I manually re add a branch deleted for inactivty.

That makes sense carneiro though we are still undecided what we think the right behaviour is here. We will review this feature request in a future update to Plan Branches later this year.

Thanks
James
Product Manager

Isn't a better solution for #2 (above) just check if the branch already exists?

This way you only worry about removing branches in the #4 situation, and avoid the need to remove 'inactive' branches for those who don't want that feature.

Right now, 'remove inactive branches' is the only way to remove branches automatically.

Does this make sense?

Nicholas,

We keep a list of branches we've created / not going to recreate. This is for two things:

1. When you enable the feature Bamboo stores the current list of branches (so it doesn't create all branches in history)
2. When a new branch is detected we add it to the list (so it doesn't get double created)
3. When a branch gets expired (ie no activity on it) the Build Plan gets deleted but the branch detected list does not. This is to ensure that the next time we fetch the list of open branches, we don't readd it again immediately
4. When the branch gets deleted from the VCS, the same happens as in #3

We currently detect new branches by getting the list of branches from the VCS and comparing it to the list we have internally in Bamboo. For Git at least, the branch list we get doesn't have a "last push date" on it AFAICT. So in order to properly see if the branch is newly updated (as per scenario #3), we'd need to check the last updated date of each branch explicitly, which can be expensive if you have a lot of branches in the system. We decided to not do this for now due to performance / load considerations.

Having said that, if your scenario is more #4 then I don't see any reason why we wouldn't delete the branch from our list, when we detect the branch is deleted from the source control system. That sounds pretty reasonable.

Hope that gives you some extra details.

Cheers,

Mark C

I think this is a bug.

This means somewhere, Bamboo is keeping a list of branch names to never re-create, right? How else could Bamboo know not to create a branch when I push a ci branch? This doesn't quite feel right. Does this list persist forever? Does that mean the list of potential branch names that can be used by our developers is constantly decreasing?

I guess I don't understand the reasoning behind the current implementation.

Hi Vincent,

Sorry this is not on the roadmap at this time.

The work around here is to either:

1. On the branch config, check the 'Do not remove branch' checkbox so that they are not deleted (recommended)
2. Set the Remove after X days value on the Branches configuration to 0 (A value of zero prevents plans from being deleted). This means all branches will stay around and not be deleted. (Be aware that if you are creating lots of branches you will need to manage the deletion of branches yourself).

Thanks,
James

Is this in the works? I am getting pestered to come up with a solution.

Hi Vincent,

This is not technically a bug. The idea is to exclude branches from deletion if you want to keep them around for longer. Automatic expiry is only good for branches that are only used for a few days then are marked forever inactive.

That said I think we could do better and just recreate the branch if we see new commits on it (as you have suggested).

Thanks for the report!

James