Multiple automatic JIRA issue transitions in GitLab commits and merges
Description
This is how a typical JIRA workflow looks like for JIRA issues:
- Currently when we use the auto transitioning of JIRA issues (https://docs.gitlab.com/ee/user/project/integrations/jira.html#jira-issue-closing-example), you have to specify a transition ID in the settings. That means based on something changing in master (merging in a merge request or a direct commit pushed to master), there's only one possible transition of a JIRA issue.
- Problem is that a JIRA issue can get into a (usually "closed" state) from multiple transitions.
- In this feature, we do the following to solve this problem:
- When the action is triggered on GitLab (i.e. change in master per above), first attempt to transition the referenced issue per the transition ID configured, and when detecting the keywords specified (https://docs.gitlab.com/ee/user/project/integrations/jira.html#jira-issue-closing-example), i.e.
Resolves / Closes / Fixes
. If successful, you are done. Otherwise, continue with the following. - Do an API call to JIRA to find all available transitions for that particular referenced issue.
- Look at all transitions available for that particular issue. Try to do a fuzzy match on the transition names with what is in the commit message / merge request description. If there is a match, activate that transition on the JIRA side.
- No particular precedence / ordering on the transitions. Just quit once you have a match.
- When the action is triggered on GitLab (i.e. change in master per above), first attempt to transition the referenced issue per the transition ID configured, and when detecting the keywords specified (https://docs.gitlab.com/ee/user/project/integrations/jira.html#jira-issue-closing-example), i.e.
- As part of this feature, we make the transition ID optional now in the settings. So if the transition ID is not filled in the settings, that means every time the algorithm above will be attempted.
- Note the precedence in the above. This is to make sure anybody using the existing mechanism will not be impacted.
- This should work with cloud offerings of JIRA and on premise offerings of JIRA, integrated with gitlab.com and on premise versions of GitLab.
Original description
ZD: https://gitlab.zendesk.com/agent/tickets/44859
Description
Currently our JIRA integration https://docs.gitlab.com/ce/project_services/jira.html only offers to transition JIRA tickets to one state only (closed or other).
A customer would like to transition the state of a JIRA ticket multiple times depending on the status/workflow in GitLab
Customer Comments
We want to be able to change a single ticket's status 3 different stages down the JIRA workflow. So when a JIRA ticket is worked on, the developer makes a new feature branch for that JIRA-ticket in GitLab off of the Epic branch; concretely there's a feature branch for each ticket. Once the branch is made, the ticket is moved to the "Dev In Progress" JIRA-stage. Then, when development is done for that ticket, a merge request to merge the feature branch into the epic branch is made for the branch, and she moves the ticket in the "Code Review" stage. When a branch is +1'ed/approved by other developers to be merged, the ticket for that branch is moved to the "Ready for QA" stage and the branch is merged into the epic branch. As you can see, we have 3 jumps essentially that we would like to enable that would be controlled from GitLab.