I have my circle.yml setup so that it builds only master branch.
general:
branches:
only:
- master
It correctly triggers build on commits to master and ignores commits on other branches. However any pull request from another branch into master does not trigger a build.
How can I structure my circle.yml to build all commits into master as well as all pull requests from other branches into master. I’m sure this is a common enough scenario and may be possible with some tweaks to yml file? Any help appreciated. Thanks!
I’m assuming when you say “pull request”, you mean “when the branch merges into master” .
Just to be clear, making a pull request wont trigger the build, only when you accept and merge the pull request it triggers a build.
Thats exactly the behavior right now – the build triggers after a pull request is merged into master. I am however trying to figure out if there is a way to trigger the build when the pull request is opened. Any ideas?
You can’t trigger a build with a pull request unfortunately, not that I know of. The reason is, because there is no commit to run. The pull request hasn’t actually made any changes in the code, so there is nothing to run. That is why it only runs when you merge the request.
What I think you want to do is prove that the pull request doesn’t break anything before you merge into master, and this is a very good idea.
What I think you should do is create a branch of master called “staging” or something like that.
Now when ever a pull request is made, it needs to be made to staging, not to master.
Now you can review and accept the request, merge it into “staging”, and then let ci run that build.
Then when the build passes you know it is good, and you can merge it into master safely.
Another approach to this is to make sure that you merge master into your working branch. Then push the working branch, and let ci run that build.
Then when you do a pull request git hub will tell you if the ci build passed or failed. And you know that master was merge into the working branch, so if you merge that back to master, it will also pass.
It is possible to trigger the build when the pull request is opened. There’s an option on the CircleCI project configuration for this under “Experimental Settings”:
The scenario support requested here is probably the most common git+ci workflow scenario out there - doing a ci build only when the PR is created, not before, to check the PR didn’t break anything, and only if it didn’t, merge it into a master branch. I don’t see a reason / need to build branches before they’re ready for testing / CI, especially taking into account pricing tied to parallel builds. Travis CI supports it out of the box. The solution suggested by mfenniak is only good for pull requests arriving from forked repos. Is there an ETA on supporting it for PRs created in the same repo?
Same request here too, we don’t want a build for every push onto a feature branch, but we would like to build the latest commit against a pull request when the PR is raised.
This should be possible using the Github API, Ibelieve TravisCI already supports this.
I help the team working on Sputnik - tool for static code review - to configure it with circle-ci.
On Travis-CI it is possible (or even it is default behaviour) to trigger a build on opening pull request, which is imho the best moment to build, run tests and perform automatic review.
I also would love to see this feature. Building on a push is great, but I also want to build on the merge commit that GitHub creates for every pull request (i.e. the head of the pr/<pull_request_id>/merge branch that GitHub creates). I understand it results in more load on CircleCI’s servers, but it seems important to test the actual result of merging a pull request, and not just the commit itself (which might be tens or hundreds of commits behind the target branch). There’s a real risk that even without merge conflicts, the tests may pass for the commit but fail once it is merged.
Additionally, I need this functionality in order to support a downstream build system I’ve pieced together using CircleCI’s experimental build parameters on their API. Without it, the process will only work if another push is made to the PR after it is opened.
It looks like this functionality has also been requested in several other threads:
Any updates on this? Triggering builds on PR mades within a repo (not only coming from forked ones) is a very useful feature, specially when it comes to private repositories.
Bump. Anything Circle team? I switched over from travis because Circle is much more friendly with iOS work, but without this feature I may need to switch back.
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 the “Only build pull requests” option.
This will still build your default branch, which typically is master. Does this sound like a proper solution to this issue in this thread?
Thanks for the update.
Having some issues with the workflow.
I have enabled the Build on PRs feature, and enabled status check on PRs in github.
What happens is PR never triggers builds, and report status always stays greyed out on github.
Is there a way for circle to trigger a build on the branch specified by pull_request[“head”][“ref”] via https://developer.github.com/v3/activity/events/types/#pullrequestevent? If Circle can do that, and pass this along to my test script (maybe through ENV) I think this would be a good workaround since I can write the logic myself in the script to exit 0 immediately if its not a pullrequestevent.
+1, seems enabled, but not obvious, pr build are sporadic, sometimes they work sometimes nothing, not always updating pr status like Travis does on GitHub
