Improves branch autolinks experiments

[nzaytsev]

Description

Added chunk matching logic for non-prefixed numbers:

• XX - is more likely issue number
• XX.XX - is less likely issue number, but still possible
• XX.XX.XX - is more likely not issue number

considered the distance from the edges of the chunk as a priority sign

the chunk that is more close to the end is more likely actual issue number

Checklist

• I have followed the guidelines in the Contributing document
• My changes follow the coding style of this project
• My changes build without any errors or warnings
• My changes have been formatted and linted
• My changes include any required corresponding changes to the documentation (including CHANGELOG.md and README.md)
• My changes have been rebased and squashed to the minimal number (typically 1) of relevant commits
• My changes have a descriptive commit message with a short title, including a Fixes $XXX - or Closes #XXX - prefix to auto-close the issue that your PR addresses

[axosoft-ramint]

I don't quite follow the logic of the added code (specifically, the priority calculation) - some comments throughout might help. @eamodio might have more insight into it.

It didn't seem to help with this case I encountered in my repo. Not a blocker for merge but would be nice if it can accommodate cases like this (the first issue is correct, the second is not):

[axosoft-ramint]

This console log should be removed. Likely left over from when you were testing it locally.

[nzaytsev]

removed

[justinrobots]

@axosoft-ramint should this one make it into 16.2 or push to the next release?

[axosoft-ramint]

@nzaytsev To help me review this PR, please explain this a bit:

considered the distance from the edges of the chunk as a priority sign

Some specific examples, including what would happen before your PR and after your PR, and an argument for why you believe this is the case:

the chunk that is more close to the end is more likely actual issue number

...would help me a lot.

Thanks!

[nzaytsev]

@axosoft-ramint - all these theses are my assumptions based on our discussions and on my experience or feeling. All of these examples was created to "tune" the manual parsing algorithm. I realize that these theses are not always true, but we can not tune this algorithm to be working always for all users and all use cases. There are many contradictory cases and I still don't know how to handle release-notes-16 branch name as it has the number in the end and it doesn't match any release-like tag name. Ideally, we should use some ML, store the dataset on our servers and use users' manual (de)assosiations as additional datasets for learning. Otherwise we're doomed to tune the current algorithm endlessly

Speaking more contcrete

considered the distance from the edges of the chunk as a priority sign

Dec 20th, 2024 at 9:43 AM, when we was discussing to numbers in the branch name release-notes-16-1 and picking between 16 and 1 @eamodio said that

They both certainly could be. I was just suggesting that if we limit the matching to one match, we'd still have a match with the -1. Assuming we'd prioritize a number at the start or end first and then inner matches

But I didn't agree with that 1 is more likely the issue number than 16 and I proposed number chunks. So, now 16-1 is a number chunk where the meaningful part is the first. Sometimes devs can call their branches like below:

• bugs/1-foo
• bugs/1-2-foo-solve-bar
• bugs/1-3-foo-fix-baz
  It means that devs work on issue 1 and have 3 revisions of the branch for some reason

the chunk that is more close to the end is more likely actual issue number

Here I applied the breadcrumbs logic. Maybe devs work on an epic with the key X and have a scope of issues inside the epic:

• X/1
• X/2
• X/3
  In this case X is still an issue key, but 1/2/3 keys are more actual and specific. Same for subtasks:
• X/1/4
• X/1/5
• X/1/6