nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Accepted answers

All comments

unknown

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

unknown

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration

git

workflow

github

git-flow

trigger