What is a pull_request synchronize event

[simonbyrne]

What precisely causes a synchronize event? The docs don’t define what it is.

[AndreaGriffiths11]

Hi @simonbyrne,

Thank you for being here! A pull_request event it’s only triggered when the pull request’s tracking branch is synchronized with the source branch for the pull request, and that happens when the source branch is updated.

[simonbyrne]

Hi Andrea,

Thanks for your reply. Do you know if it also gets triggered when the base branch (that the PR is merging into) is updated?

Thanks,

Simon

[AndreaGriffiths11]

Hey @simonbyrne,

Thanks for the follow up. What this implies is that if you push a new commit to the HEAD ref of a pull request then this “synchronize” event will be triggered. This is because the system is syncing the pull requests with the latest changes. This will NOT trigger if the base ref is updated.

[mkuijn-cb]

When the base branch is changed means: when you change the base ref (event "edited" on pull_request)

When there are pushes to the branch the PR's base ref currently points to, the "synchronize" event is not triggered.

[ventsyv]

What this implies is that if you push a new commit to the HEAD ref of a pull request then this “synchronize” event will be triggered.

Wouldn't that also trigger on.push event? For example if I do the following:

git checkout myBranch
git pull origin master
git push

If myBranch has an open pull request against the master branch, should I expect on.push, on.pull_request.synchronize, or both ?

[grigorye]

@ventsyv If I get it correctly, you'll get both events. So if you want to avoid triggering two workflow runs on push (if you register for both kinds of events), then you would need to employ some filters, e.g. like below:

on:  
  push:
    branches: [main] # Only pushes to main branch trigger the workflow.

  pull_request: {} # Pull request events (default: open, synchronized, reopened) in any branch triggers the workflow.

Just in case, the two workflow runs would still be different because of different contexts associated with push and pull_request events.

[siloKalle]

I have a monorepo where I would like to use paths as filter the specific workflows for the certain folders. But the problems is that using paths parameter does not have any affect at all. It seems that the synchronized is ruining it.

Why the documentation says that you can do that although I cannot acltually use pull_request finetune based on the "paths" parameter?

I can do it with push event, but not with pull request trigger event.

[kasvith]

im also facing another issue related to this, if i open a pr to a branch and(main to prod), and if this pr fails to build it also affect the status of base branch(main)

[Nearoo]

How come this question is asked in 2020 and there is still no documentation about it?

[carltonbrown]

How come this question is asked in 2020 and there is still no documentation about it?

Hello,

If you navigate to the pull_request event documentation and click the Action type dropdown, you can select the synchronize action type and read the documentation, which states:

A pull request's head branch was updated. For example, the head branch was updated from the base branch or new commits were pushed to the head branch.

Every push to a repository will generate a push event. A synchronize event is generated when the PR metadata is updated with the details of the push (these are asynchronous steps in GitHub).

If you want a workflow that responds to changes in the PR merge outcome, then you should subscribe to the synchronize event. There is a risk of executing the workflow twice if it subscribes to synchronize and push. But if your workflow monitors pushes that aren't connected to a PR, or aren't interested in PR state, then use only the push event.

[sergiubologa]

I was there multiple times and didn't see the dropdown. I had to find this comment to find it 😄