Show release branches containing a Jira commit

[oliverbock]

trafficstars

We have GitHub for Jira installed in our cloud Jira, and it correctly shows GitHub commits that match the Jira ID in the Commits section. We take release branches weekly and we'd like to be able to see which release branch a Jira's commits are in too, but nothing appears in the Branches section. From the documentation I understand that "Branches are linked automatically if the issue key is included in the branch name".

Manually adding all the Jira numbers to a branch name would be impractical.

It would be great if all branches matching a commit were shown in this area. (Though I guess for old commits there will be many such branches, so some kind of ordering/filtering would be necessary.)

(I get that I can do this on the git command line using git branch --contains, I am just hoping for an easier answer.)

[mboudreau]

Just for clarity, I'm guessing you're using some kind of git-flow process for releasing?

Let me know if I'm getting this correct. Your developers are creating PRs and such, which are then merged into main/master or any of your release branches, but you want that release branch to show which JIRA tickets are included under it?

We currently don't have that feature, but it is an interesting proposal. How do you think this would work since the app doesn't know what's a release branch or not?

[oliverbock]

Hi @mboudreau, yes, something like that: our devs make PRs that are merged onto master, and release branches are taken weekly from master for stabilisation until QA passes it for release. Of course we end up with heaps of branches in git (undeleted PRs, feature branches, release branches) so we use a naming scheme to help differentiate release branches. e.g. Release_20210730 for a release branch taken today.

If Jira+GitHub could filter by wildcarding (Release_*) and used inverted sorting (new dates first) then we would see new release branches up top, which is what we would generally want. Obviously if you've got an inconsistent or unsortable branch naming scheme then life will be harder, but such people are already intent on making life hard for themselves...

[mboudreau]

Alright, I'll bring it up to the team after migration for triage to see how feasible this would be and how many customers this would affect. Thanks for the suggestion :)

[ccrolf]

This is an interesting use-case that might be quite hard to achieve with the current GitHub APIs.

Have you considered tracking this information in an aggregate way instead of per-issue? For example, using the Jira release hub or DevOps metrics views?

[oliverbock]

Hi @ccrolf, so far as I can tell, using Jira deployments would require an API call to specify which deployment any particular Jira is in. We could do that automatically by scanning the release branch for Jira IDs in commit messages. Have I got that righty?

One downside to this is that any Jira can only be in one deployment so we would lose information because sometimes a Jira spans multiple deployments. This may be because preparatory release is in a separate deployment, but more often it occurs when a change needs a fix soon after release for some unexpected edge case. In this solution we lose that subtlety.

Also, we are hoping for something that doesn't require us to code the solution ourselves.

[rachellerathbone]

Hey @oliverbock. Both this issue and a related issue (#672) have been added to our roadmap. We'll update you again when we can.