Is it possible to define different target branches for pull_request and push ?

[manuzhang]

For example, I want to trigger workflow on pull_request to all branches but only on push to "main" branch. Otherwise, there will be two identical workflows if I push and open pull_requests to the same repo without fork.

[djspiewak]

Yeah this was a conscious decision. I'm certainly open to changing it, but it was intended to be this way. To resolve the issue you reference, the idea is to simply restrict both push and PR builds to main. If you do this, then you lose builds on branches which are not main, but if your workflow involves pull requests from upstream to upstream, then this is unlikely to be an issue.

[jlprat]

I wanted to chime in for this issue.
By restricting both push and PR builds to main it effectively solves the issue posted. But for projects with different branches per version (for example many OSS libraries) the workflows won't be triggered when branching or pushing to said version branches.

As an example, given project X that has the main branch and a couple of branches that maintain "current" active versions, v1.0 and v2.0. Ideally, we'd like a ci.yml like the following:

on:
  pull_request:
  push:
    # We run the ci pipeline on `main` branch for now. Once branches per versions exist, these need to be added here using a regex.
    branches:
      - main
      - v[0-9]+.x

This would effectively run only 1 instance of given pipeline when creating a Pull Request, and also when adding further commits to said PR.
Also, this would trigger builds after merging PRs to main or any version branch, making sure the "trunk" (or "trunk" of that given version) is always passing the desired workflows.

I'm fine with the defaults you (@djspiewak) chose for the tool, but would it make sense to you to add a way to override them for this particular case?

[djspiewak]

As an example, given project X that has the main branch and a couple of branches that maintain "current" active versions, v1.0 and v2.0. Ideally, we'd like a ci.yml like the following:

I'm not sure I fully understand… Wouldn't you want to have builds trigger when creating a PR against master or the v* branches? I maintain a few OSS projects which have this branching scheme and that's definitely the semantic we use.

[jlprat]

As there is no condition under the PR section it should run for any PR pointing to any branch. So this configuration should work as expected.
But I guess you are right, by having the same value in both it would run once within a PR. And for the PRs that target main or any version one.