Trigger workflow on a pull request when the base/target branch is updated

I wish to trigger a workflow in the context of a PR whenever the base/target branch of the PR is updated.

This has been asked here in past and also on StackOverflow, but without a sufficient answer IMHO.


Because the “Require branches to be up to date before merging” feature on protected branches is largely insufficient for verifying that a PR won’t break the target branch, and for two reasons:

  1. It requires manual human intervention, even in (many) cases when there’s a potential to avoid it.

  2. It forces merge-commits (from the updated target branch to the source branch) in many cases when these are not required, thus polluting the repository history.

A much better way to make sure that a PR won’t break the target branch is to run a workflow that does the following:

  1. Switch to the target branch of the PR.

  2. (locally) Merge-commit the source branch of the PR; this could obviously fail if there are conflicts.

  3. Run all the tests.

So instead of a workflow that tests the PR in a state of “before merging”, this workflow tests the PR in a state of “after merging”. It makes sure that the PR won’t break the target branch, even if it’s not “up do date”. After all, checking the “up to date” status of a PR is a poor-man’s mechanism to verify what this workflow does automatically and without side effects.

However, this workflow could only work if it could be triggered whenever the target branch is updated. I’m guessing that this type of webhook event exists even though it’s not documented; otherwise, how come the “up to date” check is triggered?

You could cheat by adding a on: push / branches: HEAD workflow which iterated over each open PR to your repository and then tried to do something to them. I suspect that a PAT w/ member permissions to your repo could be used to push empty commits into most PRs which should trigger a new round of tests.

I’d rather avoid creating commits, but perhaps adding a comment with certain text could trigger the PR to run the checks again. Thanks for the idea!

1 Like

As long as you use rebase-merge as your strategy, the empty commits should be mostly harmless.

But, yes, this is obviously a hack.