Search

b4978340ff6b,

As I updated 3 years ago, any branch you directly update is sent to Jira, regardless of whether it is in a fork. So if you use a fork-based workflow and you push all your work to your fork, those branches will appear in Jira. At this time we're not working on any further changes in this area, and it's not on my personal agenda to work on in my spare time either. Is there something specific you're still looking for? I'm not sure a day will ever come where all branches in all forks are listed in Jira. Personally, I don't see any significant value in listing every repository in a hierarchy simply because the branch is present. Especially for developers who use fork syncing, you end up with many branches present in your fork that you don't actually care about. Any branch you actually push to will appear in Jira, though.

Here's a screenshot from this issue's dev panel:

That test branch is in my personal fork of the Bitbucket Server repository. Since I pushed directly to it, it was indexed in Jira.

Best regards,
Bryan Turner
Atlassian Bitbucket

Is there any update regards?

I.e. can I today able to see in Jira issue branches from forked repo?

If the answer is not, then when it's suppose to be solved?

By the way, I know that branches from forked repo in Github and Bitbucket is working.

i_boyko,

Unfortunately, no. The new behavior is the only behavior. Trying to make it configurable per repository would add a fair amount of complexity (for the code but also, more importantly, for administrators, who would need to configure it all, and for users, who would need to understand why their branches appear in JIRA for some repositories but not all repositories without being able to go "look" at the settings).

Do you have a specific use case you're targeting?

don.draper1814139281,

I hope it's a useful improvement for many! My apologies for it taking so long to ship.

Best regards,
Bryan Turner
Atlassian Bitbucket

Hi Bryan, is it possible to disable this feature for some forks or repos?
I mean, to keep functionality as earlier when Development panel in JIRA shows main repo only
Thank you.

@Bryan  Thanks very much for taking this on!

Bitbucket Server 4.14.6 and 5.0.3 have been released with indexing for branches in forks. 5.1.0 does not include this indexing change. It will be included in 5.1.1 when that's released, and will be present in all subsequent 5.x releases.

So, to be clear:

• 5.0.0, 5.0.1 and 5.0.2 do not index branches in forks
• 5.1.0 does not index branches in forks
• 5.2.0 and all subsequent releases will index branches in forks

Apologies for the confusing set of fix versions, but it's unavoidable when backporting fixes.

Best regards,
Bryan Turner
Atlassian Bitbucket

All,

I've been working on solutions for this issue. It's going to be a multi-step process to truly solve it, and some of those changes are going to be bigger than others. Because this is such a critical issue for many, I've worked to break down the "ideal" solution into smaller parts, and, most relevantly for those watching this issue, focused on doing so in a way that will yield changes that are safe to backport. I don't want to gate getting access to a solution for this issue on upgrading to the new 5.x release series.

Cutting to the chase, I've completed the first part of the overall change, which will allow Bitbutbucket Server to index branches in forks, and I've backported that change to our 4.14.x series for inclusion in 4.14.6. (Note: It will not be backported further than this. Upgrading from any previous 4.x release to 4.14 should be reasonably straightforward, especially compared to upgrading to 5.x.) 4.14.6 has not been released yet; I'll update this issue again when it is.

This initial change indexes branches which are directly modified in all forks, personal and not. "Directly modified" includes (but is not limited to):

• Any branch pushed to any fork
• Any branch created from JIRA (or via the branch creation REST endpoints)
• Branches updated by merging pull requests

The primary activity that will not trigger branch indexing is fork syncing. Any branch that is created or updated by fork syncing will not be indexed by synchronization. This is intended to control bloat in the index, because any branch that is created or updated by fork syncing, by definition, must already exist upstream and point to the same commit. That means indexing synchronized branches is unlikely to add significant value compared to indexing fork branches where active development is being done. Additionally, because fork syncing only applies fast-forward changes, teams that use rebase-heavy workflows and fork syncing together often end up with large numbers of "dead" branches in forks, where fork syncing couldn't delete a branch when it was deleted upstream because non-fast-forward changes made the two diverge but, crucially, no actual work was done on the fork's branch. (For example, my own personal fork of the Bitbucket Server repository has over 350 such "dead" branches.) If a branch is created by fork syncing and then pushed to, or otherwise directly modified, it will be indexed at that time. Having been created or updated by fork syncing does not "blacklist" branches for indexing; it simply doesn't index them as part of synchronization.

This indexing can't be gleaned retroactively, so upgrading to a version with this change will not magically index existing branches. However, going forward, as branches are modified in forks, those branches will be indexed.

Best regards,
Bryan Turner
Atlassian Bitbucket

I just stumbled on this myself after having forked our old repo for a new phase of the project, only to find that JIRA acted like all the branches of the fork didn't exist.  This lack of functionality doesn't really make sense, and I'm now going to be forced to remake the repo as a non-fork just to make JIRA work correctly.

Agree with Don. Especially the following:

At the least, you could document this limitation in both the KB and the formal documentation.

It just so happens that we forked out main repository.   Engineering isn't going to be very happy when they hear about this long-standing (and disingenuously named) "suggestion".  In my world, if you clearly document that your software performs a function, even demoing it in a promotional video, and the software can't perform it, that's a "bug".  It could also be classified as "selling vaporware"; but I don't believe that applies here.  At the least, you could document this limitation in both the KB and the formal documentation.   Before I figured this out using "black box" techniques, Atlassian Support had asked me to reproduce "the problem" with debug logging and profile logging turned on in both Bitbucket and JIRA, and to provide the Support Zips.   A quick KB article would've saved me and Support more time than it would have taken to write the KB article, including editing, etc.  Heck, if you provide me with some basic guidelines, I'll write the KB article for you.  In my opinion, everybody would come out ahead if Atlassian invested more heavily in documentation and KB articles.  Giving customers the ability to submit KB articles might be helpful too, since I'm sure that I'm not the only customer who cares more about the next poor fellow user (not to mention the next Support engineer) to get nailed by this than Atlassian apparently does.