Feature request: Option to disable builds on commit pushes


In Travis there’s an option to dsiable builds on push:

Is there an equivalent in Circle?

I’d like to build pull requests and any updates to them, and any merges into the master branch ideally.

Pull requests not triggering build
CI_PULL_REQUEST no longer when building a PR

Hmmm - looks like this answer may provide close to what I’m looking for (I’d still like to build pull requests to any branch, not just master): Cancel automated builds, leave manual trigger only


Not sure what your flow looks like, you can add any number of branches, like /feature-.*/

You can tell CircleCi to white-list or blacklist any branch(s) you want.


Hey @drazisil - thanks for the reply.

We use a gitflow-esque workflow with feature, bugfix, hotfix and release branches, all in the form of feature/TicketName.

Using that answer however seems to suggest that commit pushes on those whitelisted branches would still trigger a build? I’d ideally like to build under the following conditions:

  • Commits to master
  • Pull requests to any branch, from any branch
  • Updates to the pull requests (GitHub seems to do a pretty good job of keeping Circle updated on this front)



I think that ANY pull request will get handled, regardless if if CircleCi is told to build on that branch or not.

So may want to test white-listing just master and then test if a PR gets built?

from wherever you would PR from/to if not master.


Thanks @drazisil - marking as “correct” for now, will update if it doesn’t work as expected.


Hi @drazisil - sorry, but this configuration means that commit pushes AND pull requests are build on any whitelisted branches, so doesn’t achieve the desired result of “stop building commit pushes”.

I’d like to leave this semi-open for a Circle employee and/or reference as a feature request to implement the switch in the original screenshot like Travis has.



Hey, did you manage to solve this somehow? We want to only run build for PRs.


Hi @shaharmor,

No, not me personally - although I haven’t really been trying.

Circle staff have told me that this feature request needs to be upvoted plenty of times before they will look at implementing it themselves.

Feel free to do so.



@robbieaverill I’d love to see this feature added. I pressed the “like” button for the original post. Is there something else I should do to “upvote” the feature request?


A decent workaround for now is the ability to exclude longer commands when the build is not running against a PR: Running specific tests only on a pull request. Makes for a messy circle.yml file though.


Also doesn’t let you ignore the CI build overall. Also a problem: if you push the commit, it gets build and skips the stuff it should do because it’s not a pull request, then you create a pull request from it, the CI build has already run but not done anything useful. It doesn’t run again.


I haven’t tried it, but you might be able to disable the push event in GitHub’s webhook to Circle, leaving the pull request event in place?


Would love to migrate iOS builds from Travis to Circle CI, but not having this option makes me hold back - because time for iOS builds is limited, and here I would waste some time on ‘work in progress’ commits, when I only want to build two branches and all PRs. Just tested today and PR to whitelisted master is not built.

So, as mentioned before, upvoting it so Circle employees can see it.


I also agree this is top priority for me.

There are two issues with the solution proposed in Running specific tests only on a pull request

  1. When you push your branch up to the remote it obviously will not be a PR at that point and will skip over testing. Then you create the PR and it will show that CI has passed even though tests have not been run yet. Only a subsequent push or a manual trigger with create a build that passes the CI_PULL_REQUEST check
  2. You’re still burning through your allotted container time by firing up a container, setting up dependencies etc on every push to every branch.

CI_PULL_REQUEST no longer when building a PR
CI_PULL_REQUEST no longer when building a PR

already asked this feature in the past, apparently like u @robbieaverill i came from travis and there i can decide what get’s built.
i vote for this feature to be implemented so i can stop builds from building if they do not have PR(regardless of commits)


@tom re: your recent comment in CI_PULL_REQUEST no longer when building a PR: this topic may be a few months old, but it is still visited semi-regularly by people with the same request. I’d still absolutely LOVE to see this implemented OOB!!

Also, if you did implement this I guarantee that your platform-wide build minutes decrease. Our organisation probably builds around 100 minutes per day, but all we actually need is about 20 minutes of build time to run the builds when pull requests are created. We don’t need or particularly care about the other 80, but there has to be cost associated with that somewhere on your end!


Thanks for the feedback Robbie - definitely makes sense as a win-win solution.


+1 would love to be able to build only PR branches.


I also would like greater control over when builds are done. It does not always make sense to do builds per commit, particularly with PR-heavy workflows.