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.

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 ?

@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.

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.

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)