Run actions on Pull Requests with merge conflicts

We have a suite of actions which allows us to build and deploy mobile apps archives from pull requests, which we use as a part of our release process and planned to use for feature development.

Workflow has been configured like this:

    types: [labeled]

if: startsWith(github.head_ref, 'release/') && == 'deploy_ios'
- ...

We have recently started to encounter problems, that actions do not start at all, if PR has any conflicts with a base branch. This is a rather interesting limitation for our use case, our current gitflow assumes possible existance of merge conflict between release/ and master branches (we cherry pick hotfixes), where in the end we would occasionally override master branch with changes from release with strategy-option (this happens because of previous release hotfixes having different parent commits).

For feature branches it’s also rather an undesired behaviour, since if I want to share a test build with my colleagues (designer, pm) to test, we don’t really care whether I’m up to date with base branch. 

In fact checkout action already allows to disable merging into base, which we use, but it doesn’t really work if you workflow doesn’t get trigged at all.

      - uses: actions/checkout@v1
          ref: ${{ github.head_ref }}

There have been some other related threads, which didn’t got much attention in the end:

Suggested approach with using on: push, doesn’t really work with labels. We know for sure that we can work it out with on: issue_comment, but it’s cumbersome and requires an extra API call to get PR context.

What would be really nice is an option in repo settings to allow run actions with merge conflicts. Or if there’s any alternative solution to configure a workflow run without looking at a conflicts and ideally with a context of a PR, would be great to know.

Thank you!


Thank you for reaching out! It’s a limitation that workflow is not triggered for ‘pull_request’ event if conflicts exist.

BTW,  please set ‘if’ expression at step level and ‘startswith()’ doesn’t accept variables, please use code sample as below:

      - if: github.head_ref == 'release' && == 'deploy_ios'
        uses: actions/checkout@v1

@weide-zhou wrote:

It’s a limitation that workflow is not triggered for ‘pull_request’ event if conflicts exist.

Hello, can you tell me if this limit still exists? I am currently facing a similar problem.

1 Like

How is this Solved? The the question is specificly asking how to trigger an action for a conflict on a pull_request and the solution does not provide any hint on how to do this.

1 Like

What exactly is the suggested course of action when a PR has merge conflicts with the master branch of a repo? Actions don’t run at all, and using Github’s merge tool causes the master branch to be merged into the PR branch. This is, IMO, super messy and not ideal.

The problem that seems to be at the root of this issue is that actions/checkout doesn’t checkout the PR’s branch, but it actually merges the branch into master. Regardless of whether it should do this or not, I would expect to see an error inside of that action’s output, instead of having the action not run at all.

Hi @adrianjost @sebr74 @JGJP,

When conflicts exist for pull request, you can get the information as below, you need to resolve the conflict firstly then event will be triggered.



The problem with the approach of “resolve your conflicts first” is the fact that my actions do not really have to do anything with code at all. E.g. I have an action, which links JIRA tickets into a description of a PR, taking it from branch name.

Or another example is an action, which would label PRs with a package name in a monorepo, which has nothing to do with code either, but requires PR context to exist

It’s hard to understand WHY pull_request action trigger has such a hard requirement of branch to be conflict-less with merge base, and the goal of this particular topic is to get to answer to this question, rather then get explanation on “please resolve merge conflicts”.


Thanks for your reply.

With all due respect, I don’t think you’re understanding the issue, because your reply offers no help or additional information.



For pull_request event, the related ref is a fake merged branch: refs/pull/:prNumber/merge, however it’s not related to actions/checkout. If there’re any conflicts, github cannot create it automatically for the workflow.

AFAIK, currently you can use web editor or command line tool (git bash) on local machine to resolve the conflicts.

Much appreciate your ideas below, according to the policy, it’s recommended to raise a feedback ticket here where github product manager will take a review.
I would expect to see an error inside of that action’s output, instead of having the action not run at all.


This is clearly a bad design. Actions aren’t necessarily related to code. Having conflicts shouldn’t be a blocker. My actions deploy the code elsewhere, and having conflicts is not an issue. Sometimes, those conflicts will never be fixed because we’re working from a v1 to v2 and use the PR as a diff tool, but don’t meant to perform an actual merge in the end.

Bypassing this default behaviour seems quite necessary. And warning about WHY a workflow doesn’t run in such case would be very welcome!


I’ve created a new shiny bot that resolves git conflicts (on lock files) automatically and pushes fixed branch back.
Unfortunately I found out that action is not triggered if PR contains conflicts :frowning:


I also think that workflow should be triggered anyway.
Let it fail on checkout or any other step, but at least there will be some kind of visibility.
Also, in this case users can control whether they want such workflows to fail, by switching to head_ref commit instead of merge commit in checkout step.

1 Like

Wasted 2-3 hours on this issue. It would never occur to me that this might be the case.

PLEASE, add a note that GH actions will not run and why.


Does anyone know a workaround for this?

Maybe run actions on push events instead, figure out if there is a PR for the branch and then skip/abort the action run prematurely if not?

If a PR in fact exists, what environment variables would we need to fake?

Or would GitHub need to add a new on: type, like on: pull_request_head:?

The pull_request_target does not solve this, since it runs against the base commit in the base repo (the PR target), not on the HEAD of the PR branch.

That’s true, but I believe you can get a ref to the head from the pull request object and checkout to it. This at least solves the problem of pull_request events not running when there are conflicts

My previous post was wrong, pull_request_target doesn’t run if there are conflicts either, it runs in the same situations just with a different context

@weide-zhou can you or somebody else confirm that behaviour changed on Github side?
We are seeing some PRs that run checks while having conflicts in UI :tada:

@dentuzhik Github workflows aren’t starting on pull requests with merge conflicts for me


name: Main Pull Request Workflow

    branches: [master]
    types: [opened, synchronize, reopened]

    runs-on: ubuntu-18.04
      - name: Print hello world
        run: echo hello world

Has anyone heard if a solution is coming?

I’ve submitted feedback, and I assume others have too, but I haven’t heard anything and it is not on the roadmap. It’s a big hole IMO and will prevent porting over of all CI functionality to actions. There are plenty of actions that can run in conflicted state and some that will even provide info that is useful to resolving the merge.

A separate trigger for workflows that don’t care about the merged code, or instead failing at checkout when used, is really needed.