CircleCI Ideas

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.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Feb 6 2018
  • Taking votes
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest 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!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    July 26, 2018 18:04

    Yes please, echo the sentiments in the comments here.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 01, 2018 21:08

    This is an absolute necessity for our workflow.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 17, 2018 11:51

    This is a necessity

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    September 05, 2018 11:28

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    November 07, 2018 09:04

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    27 Feb 07:49

    Need this for production branch whitelisting.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    01 Mar 15:50

    100% need this please

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    07 Mar 09:47

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    21 Mar 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
    10 Apr 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    25 Apr 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    01 May 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    09 May 20:06

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    14 May 20:02

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    05 Jul 20:47

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    06 Jul 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    06 Jul 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.