github-for-jira
github-for-jira copied to clipboard
atlassian
Related Jira ticket referenced in PR incorrectly having their status updated
I am not totally sure I have traced this all back to the correct place but I believe the enabling of these changes is causing some issues for our org. We have recently started noticing that related jira tickets mentioned in PR body are having the PR being associated incorrectly w/ the related jira ticket. This change in behavior is having a fallout effect of then incorrectly moving the status of the associated ticket in Jira to a state it shouldn't.
Example scenario:
- Working PROJ-2 jira ticket (
IN PROGRESS) that is a follow up to alreadyDONEPROJ-1 ticket - Commit final changes to github for PROJ-2 ticket
- create and submit PR for PROJ-2 and include summary w/ PROJ-2 (how this association use to work) and add a reference to PROJ-1 in body that is a link like
[PROJ-1](https://myorg.atlassian.net/browse/PROJ-1)so it is easily navigable by dev reviewing this PR as reference.
expected behavior: PROJ-1 that was already DONE remains in DONE state. We would also prefer the PR wasn't associated w/ the Jira ticket PROJ-1 as it isn't the PR for that ticket but that isn't a 'huge' problem for us (just adds a lot of noise).
actual behavior: PROJ-1 is auto-moved to IN REVIEW even though the PR is actually for PROJ-2
Is there a way to still allow links in PR body so devs can easily click and not trigger this auto-move behavior?
Hi @lance0428, thanks for raising!
This issue can happen regardless of how the association took place. The simplest way to prevent the problem is to ensure that automations only transition issues forwards on the board. In other words, having a condition like on PR: if not(done) transition to in-review.
In general, automatically moving issues to Done on PR merge is desirable, but often difficult to maintain. Many teams we've worked with transition into a QA/Demo/Rollout column, as some changes may be feature-flagged, which decouples the merge from the rollout to customers.
We noticed that this issue is really messing up our workflow.
We use automation in Jira so when a PR is created, it moves the jira ticket into "Review" status and when a PR is merged, it moves the jira ticket into "Merged" status. It's worked really well for us, and further feeds into the rest of our release process. We would like to be able to comment on PRs about past work we've done or future work we plan to do and reference the Jira ticket numbers for that work. However, if we mention a related jira ticket, it automatically adds the PR to that Jira ticket, which automatically moves that Jira ticket into Review/Merged along with the ticket that's actually being worked on.
Is there a way to turn off the "mentioning a jira ticket automatically associates the PR" feature?? I originally contacted Atlassian support to see if they had any control around this, but they said to go through Github.
It would be nice if the logic to include 'full PR text' vs 'PR title' when linking Jira tickets was a configurable option because we still have some tickets being linked incorrectly in Jira, but we seem to have an okay workaround for this issue.
We were using Jira Workflow Triggers that were moving our tickets. It was really hard for me to track that down but that is a issue for another day. We opted to turn those triggers off and migrate our ticket transition logic to Jira Automations. That, in combination with a naming convention we use for our branch names allowed us to have a workable solution. We include the Jira issue key in our branch names so we could write a simple automation like this:
Given this github-for-jira plugin is still incorrectly linking PRs referenced in the body we still get some 'linking' that we don't want. Like below, where we have two merge requests but only one of them is the ticket's real PR and the other is one that just happened to 'reference' this ticket in the PR comments. While this isn't ideal at least we are no longer changing status when this happen, which was turning into a real risk to managing our stories.
