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
    22 Jun 05:51pm

    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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    17 Jun 08:40pm

    bumpity bump bump bump

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    10 Jun 07:59am

    @circle common~!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    10 Jan 03:25am

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    6 Jan 10:01pm

    yes. real software products need this feature

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    2 Dec, 2019 03:39pm

    please make this! we really need it

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    2 Dec, 2019 03:32pm

    Yes, please!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    2 Dec, 2019 03:31pm

    How this not a thing

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    15 Nov, 2019 03:55pm

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    23 Oct, 2019 09:14pm

    Yes, we need this.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    1 Oct, 2019 01:41pm

    2 years later, please this is necessity.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    6 Jul, 2019 04:59pm

    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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    6 Jul, 2019 04:57pm

    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
    5 Jul, 2019 08:47pm

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    14 May, 2019 08:02pm

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    9 May, 2019 08:06pm

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    1 May, 2019 08:23am

    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
    25 Apr, 2019 01:11pm

    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
    10 Apr, 2019 09:36pm

    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
    21 Mar, 2019 02:17am

    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