Workflow not executed for a PR with merge conflict

I am testing out a Github action which is configured to run when a PR is opened on the master branch. I noticed that if there is a ‘merge conflict’ as part of the PR, the check / action / workflow is not executed.

Extract from the workflow yaml file

    branches: [ master ]

The check runs fine if Github does not find a merge conflict for a PR. Is this behavior expected ?

Below screenshot to show an example of the conflict .

Is this expected behavior.

Simulated the use case below


PR from a branch named ‘1’ with no merge conflict - resulted in the execution of the workflow

PR from a branch named ‘2’ with a merge conflict - resulted in no execution of the workflow

Can you provide a sample public repository with similar configuration?

Hi @jsoref - Thank you for the response. I tried to create a simulate the situation below

PR without a merge conflict which results in execution of the workflow

and a PR with merge conflict which results in no execution of the workflow

I believe it’s this:

Hey @jsoref
Thank for you looking into this further. However I feel like this is not an issue with the checkout action. As far as I understand , the workflow itself is not getting executed.

To test this out quickly I changed to main.yml file for the workflow to remove the checkout action and just kept some ‘echo’ statements . I still see the same behavior

Closed and reopened the PR from branch named ‘1’ and that produced the workflow run below

In total there are 2 workflow runs for the same PR (under the actions tab) .

I closed and re-opened the PR for branch named ‘2’ which has the merge conflict, and no workflow run was executed again .

Ah, indeed. Sorry about that.

For what you’re doing, today, you could try using:

    branches: "**"
    tags-ignore: "**"

Essentially, it’s a design feature that workflows do not run for pull request related events when there are conflicts.

As long as the workflow you’re running doesn’t really need to do stuff to your specific repository as opposed to a fork and as long as you understand that some forkers will not enable workflows, you’ll get some coverage.

1 Like

Hi @jsoref
Thanks for pointing to the other thread, that is precisely the issue I am facing. I guess I should have done a better job of searching before posting my question.

I looked at the suggestion you provided with the ‘push’ event . But it might not work for us, as we need to know the result of the workflow / check I am trying to implementing to decide whether to approve the PR to master. Hence the check needs to run before any code is pushed to the master branch. So using the ‘push’ event might not be a viable or too late to run the check.

I might try the “pull_request_target” option and see how that works

No worries. I did a bad job searching to find your ticket too.

If you need to know if something works, you could have a workflow that reproduces a push into a disconnected fork where the workflow is enabled.

The event dispatch decisions are the same for pull_request_target and pull_request, so that will not help.

I did some quick test . It looks like the change to ‘pull_request_target’ results in a different behavior.

After the change to main.yml . I closed and re-opened this PR which has a conflict and the workflow did get executed this time. Will need to see if this change will workout for the other things I need to run in the workflow.

Oh, right, because it’s going to target the base commit.

If you’re going to do this, be sure you use:

ok, thanks for pointing out the token permissions page. will keep that in mind.