Branch name autolinks

[nzaytsev]

We have a request to know the issue list of a branch. This knowledge gives us ability to add the linked issue(s) to the commit graph header (e.g. near to linked pull request button of current branch) and to the new home view. We thought on using name patterns similar to our existing autolinks that we use for searching issue info in commit messages, but we've faced with the list of issues.

1. Branch name patterns may be really different for each team/dev. Any restrictions lead to unexpected behavior for some user. As for me, the most usual pattern is (?(<group_name>/))<issue_key>(?(<any_space_symbol><any_escaped_additional_info>)). Issue key may be alphanumeric (like "ISSUE-123" in context of external linking such as Jira, or 'gh-123' in context of internal github linking), may be #-prefixed (like #123 in context of internal linking) and may be a simple numeric. So, usual expected branch names should looks like:

- 123
- 123-fix-something
- bugs/123
- bugs/123-fix-something
- ISSUE-123
- ISSUE-123-fix-something
- bugs/ISSUE-123`
- bugs/ISSUE-123-fix-something
- #123
- #123-fix-something
- bugs/#123
- bugs/#123-fix-something

It this concept it's easy to parse the issue key and link it, but:

1.1. What if the user adds some numeric notes the additional info, such as revision/version number etc.?

- branch-from-tag-v1
- branch-from-tag-r/2024-09-10
- ISSUE-1.v2
- ISSUE-1-add-2fa

1.2. What if the user wants to mention multiple issues in one branch? I know, it may sound strange, but it's a possible case

- make-some-change-to-fix-ISSUE-1-and-ISSUE-2
- ISSUE-1.ISSUE-2.fix-both

2. Other thoughts. GitHub support issue linking with no mentioning the issue key in the branch name. Does anybody tried to get branch issues from GitHub? I've not investigated other services yet, but I guess there will be more interesting questions

3. We support configurable autolinks that allows to add any issue key pattern manually and parse it. But github supports it too. I think it would be nice to sync the configs someday

[sergeibbb]

The variety is so big that we hardly can make a good guess for autolinking.Trying to pull the existing connections from some of services could work. But it doesn't look like we can avoid manual configuration (but we already have some, so probably we can use it).

[sergiolms]

@nzaytsev

1. Branch name patterns may be really different for each team/dev. Any restrictions lead to unexpected behavior for some user. As for me, the most usual pattern is (?(<group_name>/))<issue_key>(?(<any_space_symbol><any_escaped_additional_info>)). Issue key may be alphanumeric (like "ISSUE-123" in context of external linking such as Jira, or 'gh-123' in context of internal github linking), may be #-prefixed (like #123 in context of internal linking) and may be a simple numeric.

I'd say the easiest path in this case is looking for a Jira-like issue code in the branch name (GL-123), and otherwise try to find a regular issue code (123 or #123). Then if we have a match, try to look up the matched piece with out tracked issues.

It is not fail-proof, but I think it could be a pretty quick approach. I believe this is how it's implemented in the CLI, GKD and (maybe) GIJ (not entirely sure, I just know they look up for the Jira ticket in the PR title or description).

1.1. What if the user adds some numeric notes the additional info, such as revision/version number etc.?
1.2. What if the user wants to mention multiple issues in one branch? I know, it may sound strange, but it's a possible case

I guess that at least in a first iteration of this solution we would keep the first matching item. Not sure if ISSUE-1.v2 is a valid issue code, but If we consider .v2 isn't a valid part, then we would return a match with ISSUE-1 instead.
Another valid option is gather all matches and check them with our tracked issues.

2. Other thoughts. GitHub support issue linking with no mentioning the issue key in the branch name. Does anybody tried to get branch issues from GitHub? I've not investigated other services yet, but I guess there will be more interesting questions
3. We support configurable autolinks that allows to add any issue key pattern manually and parse it. But github supports it too. I think it would be nice to sync the configs someday

IMO it would be great if we could directly check that from other services, but I think even in GIJ they do something similar to this to link PRs to Jira tickets, right? I don't know if all support that. It would be great to gradually support it and transition from regexps.

[nzaytsev]

I'd say the easiest path in this case is looking for a Jira-like issue code in the branch name (GL-123), and otherwise try to find a regular issue code (123 or #123). Then if we have a match, try to look up the matched piece with out tracked issues.

it would mean that we can not link 2 issues from different services. maybe it makes sence, but I would think about it

I guess that at least in a first iteration of this solution we would keep the first matching item

I would agree, but the breaking example is - implement-2-fa/#123. here the 2 is the first matched item, but #123 seems more relevant

I think even in GIJ they do something similar

GIJ does simple regexp matching, but they have less issues because of Jira always guarantee the issueKey prefix

[sergiolms]

I would agree, but the breaking example is - implement-2-fa/#123. here the 2 is the first matched item, but #123 seems more relevant

Hmmm maybe we can prioritize matched numbers prefixed with #. Then we would try to find a match more similar to #123 and fallback to 2 in case we don't have any. Or just require that all (non-Jira) issue codes start with #, since we probably we don't want to autolink a branch by mistake. ie. feature/99-red-balloons here 99 should be taken as it is, not as an issue code

[nzaytsev]

Currently, I'm parsing all numbers (prefixed and non-prefixed) rounded by separating symbols (./-_^$) and sort by custom compare function that consider prefix length and matched position. I guess it should work optimal, but maybe I missed something