It would be great to have a configuration setting where Circle only builds pull requests, instead of building every time a branch is modified. I don’t think this is possible now?
In addition, would it be possible to build the merged pull requests. This would be something like
+:refs/pull/(*/merge) as opposed to
+:refs/pull/(*/head) I believe. That is based on the ref specs used by other build systems.
PRs should also build the temporary merge with target branch
This feature would be very valuable to us, too. Especially if it built the merged result (failing if there are any conflicts) as michaelwills suggests. Thanks!
I think this is the most basic requirement for a CI system. We’re waiting on this too.
That would indeed be very much appreciated. Building on every commit may be too overwhelming, specially for new projects where commit frequency is very high.
We have added functionality to only run builds when a pull request is open. To enable this functionality you can navigate to “Advanced Settings” for your project and enable “Only build pull requests” option.
Turning on this feature disables the github integration.
That’s great, thanks. However we also need to build
release/* for deployment to the app store. Is this supported?
The proposed solution still does not quite work for us as it still builds the default branch (e.g.
master). Is there a way to adjust the settings to only build PRs?
Would it work for you to put the following in your circle.yml file?
general: branches: ignore: - master
So that worked with CircleCI 1.0, which is what we did do. Unfortunately trying to do something similar on CircleCI 2.0 results in not only builds on
master being skipped, but the pull request builds being skipped, which is not really what we want. Not sure if that is a bug or intended behavior in CircleCI 2.0.
Understood. If you post the specifics what you do on 2.0, perhaps someone will spot something. Or confirm that the fault lies in Circle’s camp.
Turns out I had simply added to many branch filters (as they can be filtered at the
workflow level and at the
job level). One merely needs to filter branches at the
workflow level to get the intended behavior.