How do you trigger a workflow triggers on a pull request action to or from a specific branch?

[Jeff Ward]

We practice an incremental version of git-flow, where we encourage developers to perform code reviews on task/bugs into their own feature branches incrementally for larger bugs / tasks.  However, we don't want to perform workflow triggers on those pull request creations, only when a developer does a PR into develop or hotfix.

Is there any way to specify this to the Pull Request Created / Accepted / Rejected etc triggers that they only be performed on specific branches?

[GabrielleJ]

How do you transition the workflow in JIRA on Pull Requests? What JIRA hook are you using?

[Jeff Ward]

I believe it's part of the DVCS connector, connected with github.

[Jeff Ward]

If looks like this is not possible given the lack of response. I've added a suggestion to the JIRA bug tracker here:

https://jira.atlassian.com/browse/JRA-45422

[Yasser Abdallah]

https://confluence.atlassian.com/jirasoftware/blog/2015/07/workflow-automation-triggers

[Antonius Golly]

Though the whole internet is saying it isn't possible, it is in fact possible with some more engeneering and a little mind-shift:

• Reflect Bitbucket branches in the Jira ticket status (that is the crucial bit)
• Dfine the triggers in status to status transition (in contrast to a "from all"-transition)

Example:
Say you have this workflow: (status) [Trigger]

• PM creates ticket ("open") 
• Dev creates branch ("in progress") [T1]
• Dev works on issue
• Dev creates PR to branch develop ("in review") [T2]
• PR is merged ("staging") [T3]
• Lead creates PR to branch master
• Lead merges PR ("done") [T4]

Now, let's look at the triggers:

• T1: Create Branch trigger
• T2: Create Pull request
• T3: Pull request merged
• T4: Pull request merged

When you attach all these transitions to the "from all" transition the first merged PR will move the ticket to done, and the second PR created will move the ticket back to "in review" no matter what. That's not what you want. 

If you define individual transitions and define the trigger there, it works like a filter. 

[Henrik Zagerholm]

How will this avoid that the issue is transitioned to In review ONLY when the PR are against development branch and not against feature branches?

Maybe I do not understand "Reflect Bitbucket branches in the Jira ticket status" :)

Cheers

[marcmro]

As i just encountered the same problem i'd like to share the solution i came up with:

I restricted branches in Bitbucket such that developers/groupY can only create Pull Requests into the development Branch.

By that i don't need the ability to restrict the 'Create Pull request' trigger in Jira to a certain Branch.

[Henrik Zagerholm]

Ah ok. But does that mean that they cannot make PRs against feature branches?

Our workflows is that developers can create intermediate PRs against an Epic branch so that we get continuous reviews on both backend and frontend code even though the integration is not yet working. Then when the features is done a PR against development is created and when merged, all stories are automatically moved to QA step where all the integration tests are done. So our concern is that I do not want a Story to move to QA then an intermediate PR is made against the feature branch.

[marcmro]

Unfortunately my workaround won't work for you then.

Might try to contact support or open a Feature Request/Ticket with them.
I'm happy to Vote & Follow it if you post it here as that'll be a feature i'd like to have.