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
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