Don't match every Jira issue found in PR description

[AlecRust]

(continuing from https://github.com/atlassian/github-for-jira/issues/119#issuecomment-1010360037)

Recently you released a feature where a Jira issue ID like TEST-12 can be included in the description of a PR and automatically linked to the issue.

This is great, but it's common to refer to multiple tickets within the description of a PR, and the PR itself only be associated with one Jira ticket.

Personally, I would only expect a PR to be linked to a Jira issue if it matched something like fixes [TEST-12] or closes [TEST-12]. A special keyword would ideally be required before the issue ID, and the issue ID be "linked" i.e. wrapped with [ and ].

Any chances you could refine this feature to provide more control over this linking?

[celinakRS]

Down vote.

[mboudreau]

@AlecRust We'll have a conversation internally about this as for the most part our customers wanted this current functionality to associate all tickets in body. I'm curious about your use case though and would like to know more. Maybe give some examples. We're curious to know why you're referencing other tickets and why having that PR associated with multiple tickets is an issue.

There are a few ways to approach this that I think would work for everyone, but we need to document all the use cases first.

Thanks!

[AlecRust]

Thanks @mboudreau. I'm looking for more control over whether a PR counts as "development work for this Jira issue" like GitHub provides. For example, if a GitHub PR description contains this:

Following work in #123, this PR does X and fixes #321

It will create an association with the #123 GitHub issue, but it won't close it i.e. it's not development work for that issue. The fixes part before #321 however makes it special and means the merging of the PR will close issue #321 i.e. it is development work for that issue.

This difference between a PR merely referencing an issue vs a PR being development work for an issue would be useful.

Currently a PR that contains TEST-12 will mean it shows up in the "Development" area of that Jira issue and impacts the status labels (open, merged etc.) this integration adds.

Personally, for this integration I would expect the following matching:

• TEST-12 - Do nothing as it's doesn't have square brackets i.e. link syntax
• [TEST-12] - Turn the text into a link to the Jira issue (as it does currently)
• fixes [TEST-12] - Associate the PR as "development work" on the Jira issue
• closes [TEST-12] - Associate the PR as "development work" on the Jira issue

[ccrolf]

Hi @AlecRust, thanks for you feedback!

Atlassian is currently trying to build up a graph of devops information. For example, from above, issue 123 is related to 321 via the fix PR. But right now, the graph is still a tree with the issue as the root.

What you're describing would require having different types of arcs in the devops graph. This is quite a while away, in part because UX for setting the arc type would likely be language dependent.

I'll forward the feedback to the team that is building out the graph, and we'll leave this issue open to ensure we keep gathering feedback. However, given how many customers have requested issue key identification in the PR body, we will bias toward keeping issue association as low friction as possible.

Cheers! Christian

[callafeucht]

Would it be possible to enable customers to enable/disable each type of automatic linking? We're also experiencing tickets resolving/closing unexpectedly due to their mention in a PR body or linking in a review. It seems like enabling granular control of the linking capability would be a simple way to satisfy most customer needs.

[borisonr]

to add another example we commonly use, i may write in a description: "Additional work has been cut from the scope of this PR and will be done in ticket X" to demonstrate that we have a ticket to keep track of the followup work and that it will not fall through the cracks. But now the followup ticket closes on pr merge...

[bgvozdev]

There is an easy workaround (although ugly, but anyway, just to mention for the sake of completeness): if you replace - in issue key with something else (space, underscore), the association won't be created... ("TEST 123" – not an issue key, "TEST_123" – not an issue key, "TEST -123" – not an issue key)

[breen-laerdal]

It's a very common use case to include an "out of scope" section in a Pull Request description to indicate tickets that were not fixed in the PR.

This new functionality is causing out-of-scope tickets to be linked to PRs and then automatically moved to "done" based on our automations when the PR merges.

It would be very nice to be able to toggle off this functionality or set an explicit pattern that picks up only certain tickets linked in a Pull Request description.

[herereadthis]

Hi,

I think a lot of developers would be much happier with less complexity in the JIRA ticket matching. There would be less maintenance for the JIRA developers + less work for the rest of us who are constantly undoing JIRA automations.

Since it is a very widespread, accepted practice that devs reference ticket numbers in the titles of pull requests, how about:

Only link JIRA tickets to pull requests if and only if there's a corresponding ticket number in the pull request title. Ignore all comments, descriptions, commit messages, etc.

I took a look at your open pull requests, your titles also reference ticket numbers

[celinakRS]

I few this differently and the current implementation is less complex IMO. Many developers gather a list of commits within a single PR where each commit might reference different tickets they resolve. This is used by our server side teams but also more widely used by our mobile developers since it does require them to publish an app to the respective testing tracks. Therefore, it is still imperative to parse commits within a PR for knowing what JIRA tickets to associate with that PR. It seems overly redundant to then have a developer manually add all associated ticket numbers to the PR title when the information is already there in the included commits.

[AlecRust]

Thanks for explaining your concern 🙂

It seems overly redundant to then have a developer manually add all associated ticket numbers to the PR title when the information is already there in the included commits.

Personally I have no interest in changing the way commits are parsed, or PR titles. I am talking only about the PR description.

The problem is, that the matching of Jira ticket numbers within PR descriptions is too aggressive.

It currently matches against any instance of a ticket ID in PR description e.g. TEST-123 and links it in Jira as "development work against this ticket" which is too aggressive, considering it's common to mention other tickets in a PR description. There is no control over this behaviour. I have to not refer to other tickets which are useful when making a PR, to avoid this linking.

tl;dr: I just want the matching to behave like GitHub's

[AlecRust]

Given a PR description such as:

### Current Problem

Following [VS-111], some more issues have been identified with thing.

### Proposed Solution

Fix the thing so that it doesn't do thing.

---

closes [VS-222]
precursor to [VS-333]

As a developer using GitHub and used to GitHub's matching, I expect:

• [VS-111] to be a link only
• [VS-222] to be a link and associate this PR as development work against this ticket
• [VS-333] to be a link only

I do not expect:

All three of the mentioned tickets to have this PR associated as development work in Jira.

[sultanofcardio]

I'm not sure what the status of this issue is, but a good workaround I've found is to put your other ticket references in a PR comment instead of the description. Those don't get picked up either

[mynock]

I would also love this. At organizations I have worked at recently it is common practice to link follow-up or related tickets in the PR description as additional context. Relying only on the title/branch/commit message worked well for us so having the ability to toggle back to the previous behavior would be fantastic. Alternatively more sophisticated keyword based control would be interesting but I'd be happy with the previous behavior as a configuration option.

[robinizea]

Yes, finding every mention of anything that looks like a ticket in the PR description and considering that work to be implemented in this PR is way too aggressive.

I don't know who wants this, but I would appreciate an option to disable looking for tickets in the PR description. I only want the PR title/branch name to be checked.

[utamas]

I would even say that it is dangerous. We found our-self in a situation that a follow up ticket that was mentioned in the PR description was automatically merged and we only got it done, cause we remembered that it was important. But it means that automation failed us on very-very quietly.

This might hurt badyl trust in JIRA automation (like in our case).