How to rerun Github Actions workflow when the pull request base branch updated

Question

Is it possible to trigger Github Actions workflow when the base branch of the pull request has new code pushed?

Details with example: the pull request branch is feature1 and the base is development, so is it possible to trigger workflow on PR for feature1 branch when the development branch updated with new code after the PR opened?

Hartill

Did you try using the pull_request_target event with the synchronize type? – Phanerogam

Under most normal circumstances, you would merge the updated target branch into the feature branch, which will retrigger tests. – Cleisthenes

@Phanerogam That event has nothing to do with the target branch but rather with the target repository of a PR from a fork. See securitylab.github.com/research/… – Quintan

@Mohamed-Amer This is a great question, did you find an answer. Merging feature branches into main is also a "normal" workflow and should work. We are looking to see what the options are. The synchronized trigger isn't enough :( 'synchronize': Triggered when a pull request's head branch is updated. For example, when the head branch is updated from the base branch, when new commits are pushed to the head branch, or when the base branch is changed. It is missing the updates to the base branch. – Mudstone

Answer 1

There is not currently a trigger that would allow you do this. However, there is a feature of GitHub's branch protection rule intended to solve this problem: When selecting to "Require Status Checks to pass before merging" there is the additional option to "Require branches to be up to date before merging". This setting will block merges if commits from the base branch are not merged back into feature branches. As a consequence users will be forced to "update" their branch which will result in a "push" event to their branch thus triggering the workflows.

Medallist

Answer 2

As other answer/commenter have noted, the event trigger to re-run a job based upon an updated PR target doesn't exist. However, you can trigger a re-run with the updated target by changing the commit hash at the tip of your feature branch:

git commit --no-edit --amend
git push -f

This will work, but if you have another feature branch that continues from the old tip commit, the identical commits will count as a merge conflict when you merge the second branch. This can occur when you create small PRs for parts of a larger feature, as is typically recommended. It is possible to rebase the second feature branch on the tip of the new commit before PRing it, but you would still have to manually handle the conflict when you rebase.

Protozoon

Answer 3

Accoring to this page: https://frontside.com/blog/2020-05-26-github-actions-pull_request/

edited will do this. It is described as "title, body, or the base branch of the PR is modified"

on:
  pull_request:
    types: [ edited ]

Copyhold

"base branch of the PR modified" here means using a different branch as the base (e.g. target release instead of main). It does not mean pushing additional commits to the base branch. – Featherstone