Allow branch whitelist to override “Only build pull requests”

This is mostly copied from a thread in the Community Forum here - https://discuss.circleci.com/t/allow-branch-whitelist-to-override-only-build-pull-requests/6392

The goal is to be able to have Circle automatically build all commits to the default branch *as well as* other specially named branches without having to build non-PR branches. This is very useful for those of us who have expensive steps in our build process (like tests that run on external servers, or those using the mac OS builds who want to save minutes).

Minimum viable here would be to allow a list of branch names. Better would be to allow a list of branch names and/or regexes to specify branches.

 

We have a work-around that we developed locally by opening up fake PRs from our release branches into master as part of our process. But it's manual, error prone, and inelegant. Supporting a whitelist would be much nicer.

  • Tom Wilson
  • Feb 6 2018
  • Taking votes
  • Attach files
  • Lucas Kacher commented
    22 Jun 17:51

    This is crucial or at least some sort of workaround that re-runs execution when a pull request is opened. We are having to short-circuit executions using a job but we can't re-run the job when the PR is opened.

  • ant k commented
    17 Jun 20:40

    bumpity bump bump bump

  • Bing MunchMuch! commented
    10 Jun 07:59

    @circle common~!

  • jflay commented
    10 Jan 03:25

    All I really want is the ability to have PR Only option to also work with tags, since it's an override anyway!

  • Kevin Dixon commented
    06 Jan 22:01

    yes. real software products need this feature

  • Ruar New commented
    December 02, 2019 15:39

    please make this! we really need it

  • Ana Cuesta commented
    December 02, 2019 15:32

    Yes, please!

  • Ritchie Cargill commented
    December 02, 2019 15:31

    How this not a thing

  • Tania Petsouka commented
    November 15, 2019 15:55

    Definitely needed. We cannot follow git flow without this feature.

  • Daniel Barria commented
    October 23, 2019 21:14

    Yes, we need this.

  • Ahmed Hamed commented
    October 01, 2019 13:41

    2 years later, please this is necessity.

  • Michael Smith commented
    July 06, 2019 16:59

    Our current workaround is to build every push of every branch, but to get SonarCloud checks to show up on a PR you have to remember to re-run the build after you open the PR.

  • Michael Smith commented
    July 06, 2019 16:57

    We have a few levels of pre-release and release branches corresponding to different environments, so we need to build those branches when PRs are merged into them. We also need to trigger builds when PRs are opened so we can call SonarCloud and have it add its checks to the GitHub PR.

    So we need to build a few configured branches on every push; branches that have PRs opened against any branch (to support stacked PRs); and every subsequent push to one of those PRs.

  • Phil Leger commented
    July 05, 2019 20:47

    Yes please add this, having a /release branch is fairly common :)

  • Scott Pierce commented
    May 14, 2019 20:02

    Not having this makes it difficult to have release branches while also using GitFlow.

  • David Chen commented
    May 09, 2019 20:06

    Not the exact same thing but does using "branches" inside the configuration help for people who need this use case?

  • Adrian Hooper commented
    May 01, 2019 08:23

    This is a huge issue for us. We're using the git flow structure, and it seems impossible to filter out feature branches but still build PR's for those branches. The only solutions I can come up with is to setup a separate script that handles the webhook, does the filtering and triggers a build via the API instead which I really shouldn't have to do.

    Very disappointed to have setup the workflow and got everything to find this limitation.

  • David Harris commented
    April 25, 2019 13:11

    This is critical for our CI/CD flow, as we soak a release branch each week (for mobile app store submission purposes) and have to open an "empty" PR every single week to trigger the tasks, which gets very confusing especially if we have mutliple release branches or need some alpha functionality off alpha branches. It also makes that trigger impossible to automate easily, as we then have to dip into the Github API to do extra tasks just to automate our release builds.

  • Kunal Jain commented
    April 10, 2019 21:36

    Thank you so much for your interest in this feature. Adding a regex to specify branches in conjunction with turning on the `only build pr` settings would enhance the current functionality. We are still in process of capturing feedback on this feature. We will definitely reach out once we start the initial design.

  • Mike Deverell commented
    March 21, 2019 02:17

    As an alternative, the ability to have `pull_requests` and/or `no_pull_requests` under a job's `filters` in the config.yaml which overrides the global "Only build pull requests" setting could also work.

  • Load older comments