Show an explanation for why Actions workflows aren't run on PRs when there is a merge conflict

[danielcompton]

I spent a chunk of time trying to understand why my Actions weren't running on a PR. Eventually I realised that it was because Actions aren't triggered on PRs if there is a merge conflict. This behaviour makes some amount of sense as the SHA that Actions uses is the merge commit, not the actual commit on the branch (#github/docs#15302).

However, it would be great if there was an explanation in the PR UI explaining why. Currently everything is blank which made me think there was a problem with my workflow YAML file, but nothing showed up in the Actions list either.

Here’s what I see:

(The successful check in the UI is from an external system, not Actions)

Related: https://github.community/t/run-actions-on-pull-requests-with-merge-conflicts/17104

[ethomson]

Hi @danielcompton - thanks for the feedback. Your analysis is spot on - if we can't merge the PR then we can't build the merge result. I'll talk to the team and see how we can make this clearer and we'll put some work on the backlog. Thanks!

[fru2zzy]

any solutions so far?

[mauritsdebruin]

plz fix

[rtk-willm]

this is still a confusing issue in 2024. Gitlab triggers CI runs on all commits so quite confusing for someone coming from that world trying to make sense as to why no checks are running. I spent some time triggering white space commits, empty commits and code commits in attempts to get checks working again, assuming there was some bug on GH end.
A simple prompt in the UI explaining why no checks would save a lot of time.

[jjb]

if we can't merge the PR then we can't build the merge result

i use and enjoy GHA extensively for many mission-critical things. NONE of my uses of it depend on the concept of "this must apply to the merge result." because of this behavior, i simply have to consider GHA to be nonfunctional until conflicts are resolved, which impedes many things for my team.

[asaphe]

any updates for this issue? this is very confusing. developers expect the checks to run even if there are conflicts. maybe we are doing something wrong but more than person have asked for this to be resolved.

[cjgraydon]

This is also a problem when a PR is not going to be merged directly, but will be resolved with a force push.

Scenario:

An internal branch is rebased on an upstream branch. We mirror an upstream branch to our internal repo, which we then rebase our internal changes on top weekly.

We open a PR with the rebased branch to run CI on it. If all goes well, we force push new version over old version of the internal branch.

If there is a merge conflict, however, it breaks the CI run. Worse, if the conflict is due to something like an internal file being upstreamed and and removed on internal branch, OR is moved in the tree, it gets seen as a conflict, even though it is in the correct place when pulled in via the rebase. Note that this scenario resolves properly at the command line. But GitHub still sees it and breaks CI.

In other words, in the moved/deleted file scenario, there is literally no way to resolve a conflict at the command line that git doesn't see, but GitHub still manages to spot it and fails to resolve in the same fashion that git does. Basically, a 3-way merge fails for GitHub that does not fail for git command line.

If there is a way to get around that, I'd love to know what it is.