Run actions on Pull Requests with merge conflicts

[dentuzhik]

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:

on:
  pull_request:
    types: [labeled]
jobs:

my-deploy-job:

if: startsWith(github.head_ref, 'release/') && github.event.label.name == 'deploy_ios'

steps:

...

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.

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

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

https://github.community/t5/GitHub-Actions/Support-pull-request-events-without-merge-commit-into-the-target/m-p/36190#M2470

actions/checkout#15

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!

[weide-zhou]

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:

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

[mrhip]

Good!

[adrianjost]

@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.

[sebr74]

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.

[JGJP]

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.

[weide-zhou]

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.

Thanks

[dentuzhik]

@weide-zhou

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”.

[JGJP]

@weide-zhou

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.

[weide-zhou]

Hi @JGJP,

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.

Thanks

[Vadorequest]

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!

[alex-verve]

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 😦

[akonokhov]

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.

[molszanski]

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.

packhelp 2020-08-12 11-11-22954×612 49.5 KB

[mpdude]

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:?

[mpdude]

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.

[obermillerk]

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

[Sherlock1Li]

+1. I set up an action aiming to resolve version conflict automatically, but it turns out this action is not going to run at all when there is a version conflict...

[TE-RBP]

+1. This constraint does not make sense.

[kmalmur]

this is so frustrating. When working with submodules, the submodule pointer will almost always have conflicts at some stage of the PR lifecycle

[jamiedoornbos-evolutioniq]

I'm also running into this issue in testing a pre-merge workflow. I checked out an old branch that should have failed the merge check, but didn't, then applied my workflow fix, and created a draft PR. I was hoping to see the expected failure, but instead no actions run due to the fact that the main branch has moved on now and has conflicts with the old branch. It's just more work for me now, because I have to create a new branch on main and re-construct the errors from the old branch. It will take a little time.

[indiarasabarreto]

Conflitos de merge envolvem alterações concorrentes na linha usando o editor de confllitos.Uma das opções de resolução é quando pessoas fazem alterações diferentes na mesma linha do mesmo arquivo em diferentes branches no seu repositório Git. Então, qualquer ou todos os outros tipos de conflite de merge, resolva ele localmente com linha de comando usando Git.

( https://docs.github.com/pt/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line)

PS.: usar editor de conflitos do GitbHub para resoluções de conflitos de merge de alterações de linha de comando entre branches que fazendo parte de uma solicitação de Pull.

(https://docs.github.com/pt/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github).

[Aarbel]

+1 here, we should be able to run github actions with PR that have merge conflicts

[bsshenrique]

+1, 5 years later.
Maybe update the docs or creating an advice on PR?

[mqtthiqs]

+1, bitten by this too.

[kigary]

+1, this is somehow funny as well, that support still didn't answer or provide anything meaningful 💀

[guypeer2]

+1, at least provide some details about it in the docs or provide a notification that it won't run for whatever reason

[simonweil]

This is so annoying, is there a timeline to change this?

[Roy-Gal-Git]

How come this bug is ignored for almost 5 years?
What do conflicts have to do with CI running or not?

[make-github-pseudonymous-again]

Here is how to interpret the situation in my opinion: it makes little sense to merge a PR without having run certain types of checks (builds, tests, ...) on the merged result, i.e. GitHub would receive (or perhaps already has received in the past) complaints that PR checks says "all green" when some main branch checks are red after the merge (for instance, semantically incompatible PRs merged in sequence without rebasing/merging one on top of the other).

There are workarounds, such as running on pull_request_target or push, with some big caveats mentioned above.

Now, GitHub has been implementing a "merge queue" whose job is exactly to merge PRs in sequence and run checks on the merged result. If you use both pull_request and merge_group triggers, then yes it makes little sense to go through the trouble of running the checks twice on the merge result and perhaps GitHub should allow us to have the PR source be exactly what the PR branch head points to (and not some merged result). Ideally, this merge queue logic should be automated and relatively hidden to the user. Indeed why not duplicate pull_request triggers into merge_group triggers automatically? Well, maybe because some PR checks make little sense when they are not attached to a PR. Maybe the solution would be to do this the other way around? Automatically duplicate merge_group checks into pull_request checks? Well maybe that depends on your use case. Another solution is perhaps for GitHub to add yet another type of event, such as pull_request_push???

[Crismon96]

Can you please add this now. This is clearly a requirement and I don't want or have to resolve conflicts to gain value from running actions.
Some conflicts are hard to solve and I want get my damn virtual environment up for QA to test. I don't care about conflicts here.

[xander-marjoram]

I think this issue is also affecting us.

We have some workflows that create GitHub (and third-party) deployments for PRs. When the PR is merged or closed without merging, we have another workflow that removes all of these deployments.

Currently, this is not being run for many of our PRs, meaning we have lots of stale deployments hanging around. This also means we occasionally hit deployment limits which causes issues with making new deployments.