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!

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.

We're watching.

We've looked at what it would take to implement a solution. It's a fairly complex issue with performance implications that we need to be mindful of, so I'm working with the engineering teams to schedule it with the expertise required. We don't currently have a timeline that we can share.

Hello,

We have been expecting an update on this indeed.

Anyone from Atlassian watching ?

Hi,

Any new with this issue? An expected date to be fixed?

Also, is there any 'official' work-around?

Thanks,

Idan

m4, Thank You Very Much. My team was heppy! I've been waiting for all this year. 

bturner, could you please take a look on the points below and share your thoughts with us?

First of all thanks a lot you spent some time to review the code and make the status of our plugin clear to every one. We uploaded it to bitbucket.org (not marketplace) so everyone could see the implementation details. And we are really glad to hear the solid solution from Atlassain is on its' way!

Meanwhile try to understand below reasons we created and use our "dirty hack".

1. We have a Bitbucket Server as a primary GIT hosting system. We made our choice about 2 years ago. And nowadays our company's business (software development actually) MUST use forks. We do not have any options here.
   And we were really disappointed found the "branches in forks" indexing issue. More over workflow triggers in JIRA does not work on "Created branch" event in forks as well. So we could not proceed with forks under Bitbucket hosting with such issues. 
   Should we considered to get rid of Bitbucket and switch to some other solution? I think not.
2. We are with Atlassian technology stack from 2006, starting from JIRA 3.x. And we have learnt from Atlassian much. We like your software a lot and we (as an internal development team in the company) dig into the code of each application quite deeply.
   At the same time we understood that making a solid solution which actually should be in core could lead to considerable waste of time/efforts/money – good example is 'needs work' status.
   If you check our initial version there is no any reflection but the only adding the same type of record into your active object. Definitely not a best practice but quite safe.
   So quick working solution is the best choice in the certain circumstances , isn't it?

Finally, I was on the last Summit and spent some time at the Atlassian Bitbucket booth discussing some particular issues and potential Atlassian's plans to fix/change those in core. I got like definitely not in the nearest time for fork branch indexing...

If you would interested in some summary of those discussions you could reach me karpov@devexperts.com 

bturner, You totally rights, but we have to make a solution right now. This issue is two years old, and no solution of this problem presented.

I know, what "dirty hacks" it bad idea. When I try to solve this problem I considered two way: first - dirty hacks, second - our implementation all of yours mechanism for forks (branch listener, call-back from JIRA via update-summary REST, Specific module descriptor (I don't remember how it named now)). In second option, I would spend a lot of time and finally thrown into the garbage, when Atlassian provides our solution. Like it happens with "Need Works" status of PR. 

Technically, I make a two mistakes: I must validate BB version, which plugin tested. And I must check Entitiy fields for expected set. If You make changes, my plugin does not start. I will do it on this week. 

To all: Bryan right, You use them at your own risk., but I will be very happy if my plugin to help someone.

Have a nice day!

Having reviewed that plugin, I'd strongly discourage anyone from installing it.

I recognize that this is an important issue for many, and that it's something we need to address. But using Reflection to access things below our API and start mucking with the internals of other plugins is an extremely bad idea. Any change we make to that plugin is likely to result in strange errors or outright data corruption, and you have no assurance of support from us to recover it. Our database tables, and the internal implementations of our components, are not API. You use them at your own risk.

I would encourage everyone to please be patient. We've discussed various approaches, and some can be implemented more quickly than others. While I can't guarantee when one of them will ship, I assure you all we're aware of the sensitivity of this issue.

Best regards,
Bryan Turner
Atlassian Bitbucket

wir_wolf, i build new version of plugin: https://bitbucket.org/klissan13/fork-branch-indexer/downloads/fork-branch-indexer-3.obr

Can you check it?

Plugin totally rewrited and uses a lot of reflection and dirty hacks for accessing to active objects instead of boring direct SQL queiries.

I hope what pluign will be work with any bitibucket supported database.

As next step I plan introduce setting in UI for allow indexing personal forks.

wir_wolf, sorry. Fixed

https://bitbucket.org/klissan13/fork-branch-indexer/issues/2/plugin-not-works-with-mysql - Access denied

wir_wolf, I created issue: https://bitbucket.org/klissan13/fork-branch-indexer/issues/2/plugin-not-works-with-mysql

Plugin works with normal repositories, because it skips it =)

I use MySQL 5.7 Why plugin works fine with postgresql only? If i create branch not in fork system worked normaly.

wir_wolf, which database you uses? Our plugins works fine with postgresql only.

Yes, branch name contains issue key

wir_wolf, can you provide more details? What is branch name which you creates? Does it contains issue key?

Andrey Karpov, Thank you for your improvement but I have it throws an error after create branch in my atlassian-jira.log http://pastebin.com/893BXP1b
Atlassian JIRA
Version : 7.2.3

aps1, fill free to remove the second condition from below line of code @ fork-branch-indexer / src / main / java / com / devexperts / bitbucket / RepositoryRefsChangedListener.java

 if (repository.isFork() && repository.getProject().getType() != ProjectType.PERSONAL) {

I guessed it would require new branches, but unfortunately I was hoping for something that would work on personal forks. No problem.

aps1, Do not expect existing branches be displayed in JIRA issues. That solution works for newly created branches only. We also constraint the indexing of personal forks.

So to test you need to create a new branch in non-personal fork repository and check the related JIRA issue.

Can't get it to work at the moment, installed fine, but nothing happening. I'll have to have more of a play when I've got the time.

No problem, I probably would have figured that out eventually

I'll see if I can install it and have a play.

aps1, uploaded to repo: https://bitbucket.org/klissan13/fork-branch-indexer/downloads/fork-branch-indexer-2.jar

Please note that is a Bitbucket Server plugin but not JIRA one.

Andrey,

very interested in your plugin, but I'm not familiar with building custom JIRA plugins and I'm probably being lazy, do you have any pre-built binaries that I can have a play with?

Adam

bturner, rbarnes, thanks a lot to start looking into the issue closely!

The performance pain of branches re-index to support full forking scenario is quite understandable for Server. Hope you will find effective consistent and maintainable solution!

Meanwhile for those developers who really need that for the day-to-day process it is quite easy to made a temporary solution (plug-in) which could be substituted with the solid one from Atlassian as soon as it is ready for production.

The solution does not cover all cases but works well most of those. Each newly created branch is "indexed" (based on issue key within the name) to be visible by standard JIRA integration. That occurs only in case the branch with the same name does not exist in the parent repository.

Please fill free to check one of possible implementation we have tested – https://bitbucket.org/klissan13/fork-branch-indexer 

Roger and Bryan.

I think that as a final customer of your product, when I came here and I saw that this is an open bug since 30/Mar/2014, it couldn't sound worst to me. I'm not saying this is a simple bug to fix for sure (also because this isn't in my scope) but I'm feeling like "left in the middle of nowhere" without any understanding on how much time it will take. This is the way I'm feeling now. I can only immagine the amount of work you're involved in (I'm a developer too as most of the people here) and how difficult it could be to work on a topic like that, but (as final and paying customer) what count for me the most is to have the entire workflow working.

Our company is growing the quickest way possible and we will increase our IT sooner than later. I'm asking you to try to fix it as soon as possible just because I'm feeling good using your tools (we are currently using JIRA, BitBucket and Confluence) but, as a long term solution, I can't state that in the future we won't need to migrate to something else that will allow us managing the entire workflow, forking included.

I think I've wrote enough. I hope you will help us soon on that.

Thank you.

Apologies for not updating sooner. As a PM, I'm very fortunate to have someone like Bryan covering for lack of updates on this particular issue. It's not our intention nor preference to leave comments on this issue tracker unaddressed. We can do better, and plan to provide status updates on the top 50 suggestions (of which this is one).

@bturner

That's what's missing here, this issue has been around for a long time without any update.

It's good to know it's being investigated, personally I'll wait for an update on what you guys decide to do with it.

PM can also reply here with his thoughts

jkodroff224770933

I appreciate your feedback, both your sentiment and the care with which you expressed it. That said, I stand by my responses, both that one and this one. I didn't say anything unprofessional or insulting; I only stated that claiming we've made "very little improvement" to the product is untrue, and provided examples of some fairly significant improvements we've made. You may take my response as rude or defensive, but I assure you it was anything but. I'm not "having a bad day;" I'm simply encouraging a more measured discussion, and that can only benefit everyone.

I use a fork-based workflow. We have internal teams which use fork-based workflows. We're seeing this issue internally with our own JIRA issues for some of our projects which use forks. I designed and developed Bitbucket Server's ref sync functionality in response to a pain point in fork-based workflows. I'm extremely empathetic to pain points in fork-based workflow; they impact me daily.

As I've said, we're actively looking at this. Does that mean it'll be fixed in a week? No. I can't say for sure what release will include changes for this; I can only say we're not ignoring your feedback, or the fact that this issue is causing people pain.

Best regards,
Bryan Turner
Atlassian Bitbucket

Bryan,

Atlassian makes a lot of good products with a large feature set. However, I think you can understand that when users discover this limitation, it really kills the usefulness of forks, and as paying customers, we feel that we've been sold an incomplete product. Bitbucket Server is not the only product for which I've found what I consider to be a major hole in expected functionality, and Atlassian has not been particularly empathetic or responsive to the issue.

I don't think this is the kind of response you want to give a customer who's frustrated with your product. I understand you might be having a bad day - it happens to all of us - but getting defensive with customers is never the tact you want to take.

You might want to consider deleting your comment (as well as my response if you see fit).

Regards,
Josh

thepickle

That seems a little uncharitable, even in hyperbole. We've improved a lot of things in the product, from merge strategies to dashboards to iterative review for pull requests. You might not be a fan of the priority given to some things you care about, but saying we've made very little improvement is entirely untrue.

As for this issue, it is being actively looked at. For your information, I've spent quite a few hours in recent days looking at options and considering their performance. I didn't respond after the "ask the product manager" comment because I'm not the PM; I'm the principal developer. It's not my place to respond for him. But I will say that I'm looking at this issue specifically because PM has asked for us investigate options and try to get this turned around.

Seek first to understand...

Best regards,
Bryan Turner
Atlassian Bitbucket

Don't count on anything from Atlassian BitBucket (Server) .. I've seen very little improvement in this product since I tried it a year or two ago.
My organization is using GitLab CE now. Your loss, Atlassian.

Same problem for us.

Could you ask the product manager to review this ticket ?

My organisation is waiting for this too.

Hi there. I've just been redirected here from another ticket. Could you please update us regarding this bug? Could you give us an idea of when this problem will be probably fixed? Adopting the fork workflow is a priority for our company, thank you.

Hi, any news about this issue?

Does anyone know if Bamboo suffers from the same issue?

I completely agree. I've just spent another $5000 on an upgrade of JIRA licenses. So we've probably spend almost $10k in the past 12-18 months. And we're a long way from a big user, there must be plenty of larger users out there having the same problems. So it's a real shame to see such an important internal integration issue not being given any time at all (best I can tell).

Hopefully if we can get some traction on here then Atlassian "might" (I'm certainly not holding my breath) do something about it!

This is very disappointing to learn after my company has already invested much effort and money in the Atlassian suite. It's not a deal-breaker to be sure, but this is a fairly glaring hole in the BB/JIRA integration story.

hi, we've just started to use the combination of JIRA-Confluence-Bitbucket-Hipchat and recently discovered this problem as well. Is there a plan to address this at Atlassian?? It's obvious this must be supported otherwise please don't talk about integration between JIRA and Bitbucket like you do. It doesn't feel any good and makes me to start thinking about alternative products instead of buing licences for Bitbucket.

Is this fixed?

This is a pretty big deal for us here at Apple too. Several users complaining and reporting and it comes in time when we are deciding between Stash and Gerrit.

In that case can I suggest that you a) stop posting about how wonderful the forking model is and that Stash/Bitbucket supports it and/or b) make it ABSOLUTELY clear that using such a model will NOT work properly if you intend to integrate with your flagship product, JIRA. I've spent something like $7500 to find that such an obvious feature (well it's obvious to me and many others) isn't actually properly supported and therefore for proper traceability / audit trail we CANNOT use the fork model since it means that such changes are not visible to people in JIRA.

This is VERY poor showing in my opinion.

Adam

Hi everyone,

Apologies for the lack of an update on this. Unfortunately, addressing this suggestion is not currently on our schedule due to other priorities. We plan to resolve several other top voted feature requests over coming months.

We will update this issue when we have a better idea of when we might start working on it.

Serge, don't hold your breath. I had a conference call with Atlassian on this issue, and basically the JIRA team bounced it on account of it needing support from Stash team, who were supposed to be updating the issue to at least acknowledge the issue. That was several weeks ago, I've pretty much come to the conclusion that Atlassian care little for the issue.

The fact that the Stash team like to sing about how wonderful the fork model is (I tend to agree) and that they support it and the JIRA/Stash team both like to say how well the two integrate. Yet this rather glaring omission (that the integration doesn't work if using forks) doesn't seem to worry them!

Really wish I'd discovered this BEFORE migrating everyone, unfortunately having done so, backing out now is a non-trivial process. I just hope that if Atlassian finally fix this issue AFTER my support contract runs out that they do the decent thing and offer everyone a FREE upgrade as this is in my opinion a critical BUGFIX (not a feature change as they'd like to think).

I would like to have a solution for this as well. Forking is a very common practice and making forked branches visible in JIRA is something that developers need.

Just stumbled upon this rather large limitation, having just moved everyone over wholesale from Mantis/SVN to JIRA/Stash, and bestowing the virtues of using user forks and branches within (a pretty standard and well used model), it's very disappointing to find that this does not work!

It basically means that using this standard model the entire audit trail, during the in-progress phase, will be completely hidden from within JIRA. A limitation we certainly didn't have with Mantis/JIRA.

For me this is a really key feature and something I'd like to see the £k's I've just spent be used for!

At the very least, for a commercial product, I'd like to see some idea of a timeline as to when this feature will be available. Maybe the support request I filed, assuming this MUST be a configuration issue, will help highlight such.