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
  • Andrew Ayers commented
    March 15, 2018 14:57

    I think this is a really common scenario for people with multiple protected branches corresponding to multiple development environments. This really needs to get implemented!

  • Nick Wilson commented
    June 08, 2018 16:00

    The lack of this feature is a bit of a deal-breaker for anyone wishing to use GitFlow or similar branching semantics.

  • Alejandro Martínez commented
    June 19, 2018 15:32

    This is really necessary specially for the ones that use mac OS builds as it has a limit amount of time allowed.

  • Brian Vogelgesang commented
    July 26, 2018 18:04

    Yes please, echo the sentiments in the comments here.

  • Ryan Payne commented
    August 01, 2018 21:08

    This is an absolute necessity for our workflow.

  • Chintan Shah commented
    August 17, 2018 11:51

    This is a necessity

  • Franz Busch commented
    September 05, 2018 11:28

    This is also crucial for some of our core pull request features

  • David Stothers commented
    November 07, 2018 09:04

    We require this functionality as well. Ideally it would be behind a regex.

  • sonia cook-broen commented
    November 09, 2018 20:17

    This is very much needed, the setting is like a sledgehammer when you need a scalpel as it is today.

  • Raiyan Kabir commented
    November 12, 2018 18:05

    This is absolutely necessary feature. As we want PR to build and run tests before merge. But we want the artefacts to be stored for the specific branch on a bucket.

  • Mitchell Huang commented
    February 27, 2019 07:49

    Need this for production branch whitelisting.

  • Rich Cooper commented
    March 01, 2019 15:50

    100% need this please

  • Devin Beeuwkes commented
    March 07, 2019 09:47

    Definitely need this to run jobs on our beta and production branches (and PRs)

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

  • Admin
    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.

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

  • 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 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?

  • Scott Pierce commented
    May 14, 2019 20:02

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

  • Phil Leger commented
    July 05, 2019 20:47

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

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

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

  • Ahmed Hamed commented
    October 01, 2019 13:41

    2 years later, please this is necessity.

  • Daniel Barria commented
    October 23, 2019 21:14

    Yes, we need this.

  • Tania Petsouka commented
    November 15, 2019 15:55

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

  • Ritchie Cargill commented
    December 02, 2019 15:31

    How this not a thing

  • Ana Cuesta commented
    December 02, 2019 15:32

    Yes, please!

  • Ruar New commented
    December 02, 2019 15:39

    please make this! we really need it

  • Kevin Dixon commented
    06 Jan 22:01

    yes. real software products need this feature

  • 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!