Customising default filters

[Former user]

Hi there,

Is there a way we can customise the default filters which seem to assume gitflow is being used?

for example, we might have a branch of class */integration, for example.

[Julius Davies [bit-booster.com]]

It's based on the repository's branching model.

Click on repository settings --> branching model. Since Bitbucket 5.2.0 I think the values inherit from "project settings --> branching model" but they can be overridden.

Note: if the repo has the "automatic merging" feature enabled, it's best to leave the "production" and "release" config alone, since "automatic merging" feature also uses this config to figure out what automatic merges to perform. But all the other parts of the branching model are essentially cosmetic and can be adjusted without any significant impact.

[Jack Sussmilch]

It looks like this is hard coded via the soy/bbGraph.soy file and the relevant classes.

It would be nice if we could customise the labels for the major branch classes and define the filter. As an example: Integration /integ/ to specify a filter of name Integration which parses the branches which have anything before or after the word integ.

Customised branch classes become particularly important for the larger scale, more complex development work which gitflow can't cater for.

In the itnerim, we will just train the devs into putting the keywords in the search box.

[Jack Sussmilch]

Hi Silvie,

Thank you for your response, my browser refershed just after I commented. Unfortuantely the stash branching model characteristics are limiting us as well. I will see what I can do there though.

[Julius Davies [bit-booster.com]]

I am willing to add 2 additional filters while still tapping into branching model. (e.g., Branching Model + 2 extra slots).

Some ability to configure "commit graph" is in the works, should be released in 6-8 weeks. It will have some "freemium" tie-ins that I hope won't annoy people too much. (Basically require people install our paid add-on, but they can quickly uninstall it immediately afterwards and all config changes to "commit graph" will persist. No need to actually pay.)

[Jack Sussmilch]

Yep, as I thought, the Stash branching Model settings are too limiting as well, oh well, the consistent branch nomenclature will at least help us using the custom search text box. Just as a bit of background, the demands on our branching strategy are extensive (a lot of parellel development of releases and subsystems). The branching strategy works well, it's just many times the tooling assumes serial release management/project centric SCM.

Thank you for the quick response Sylvie.

[Julius Davies [bit-booster.com]]

Would two filter slots that support before/after wildcards be enough?

[Jack Sussmilch]

Sylvie, In our context, we have master(already there), Release Master (Required), Develop (Already there),feature (There but requiring a wildcard at the start rather than the end), hotfix and integration (Required). Examples follow: master /master - release master /develop - develop /integration - integration /feature/ - feature branches /hotfix/* - hotfix

We don't use release or bugfix in this context.

[Julius Davies [bit-booster.com]]

p.s. If the "commit graph" add-on is working well for your shop, we could use some customer testimonials on marketplace.atlassian.com!

Also, what do you put into the search box? JIRA tickets? Or other things?

[Julius Davies [bit-booster.com]]

Anyway, we'll figure something out. Stay tuned!

[Jack Sussmilch]

Hi Sylvie,

Your tool is an awesome improvement on the network diagram. It has been a relief to see it there.

All our branches are created through automations which ensure a consistent naming convention for branches, tags etc. So as a hypothetical example, a release master branch for project banana would be something like: bananar1/master for release 1 bananar2/master for release 2

Off each of these, we have larger sections of works (lets call them major compartments and minor compartments) with predominantly serial iterations for each minor compartment, so the develop branches coming off the release master branches would be something like: bananar1-C1-c2-3/develop for Major compartment 1, minor compartment 2, iteration 3

so using the text search box, we can use the filters by project, release, Major+minor compartment and the iterations thereof.

Tags are effectively in the format of <GITREPO>-<BRANCHNAME>-<INCREMENTAL_NUMBER>

Wildcards, are, of course, essential.

I will check to see if we can do a testimonial, but I can't guarantee anything due to the nature of the industry. I will try