I have a few workflows that run when commits are pushed to particular branches, such as tests when commits are pushed to feature-branches and then a build/deploy when pushed to develop, etc.
What I’d really like is to mimic our previous Jenkins setup where jobs could be triggered when PRs were opened rather than just relying on commits being pushed.
So for example:
If I have a feature branch, I can commit to it and push it without worrying about triggering too many redundant builds, and then when I create a PR to merge my feature into develop, have a job trigger at that point to run the tests, and then if they succeed and I merge the PR, the build/deploy job runs when that PR is merged to develop.
Is this possible?
Right now on circle, I have a setup where my tests are run with every commit that’s pushed to a feature branch, which is a bit much. It means that we don’t push our commits to the remote as often as we used to because we don’t want to rack up too much of a bill running too many builds…
Also, after our development workflow is done, and we’re happy everything is good, we create a PR to merge develop into master. At the moment, this doesn’t trigger anything on Circle, because no new commits have been pushed anywhere yet, so there’s no way to trigger the test jobs for dev->master, so we’re uncertain whether the tests still pass before doing the merge.
When this option is enabled, builds will only be triggered when you create a pull-request, and again when you merge the pull-request to the default branch.
So in your case, you’ll need to set develop as the default branch, if you’d like to trigger builds upon merging pull-requests to develop.
Yeah, I looked into that feature. I think it gets me 99% of the way there, but the last part of wanting a workflow to trigger on merges to the master branch (which isn’t default) gets left behind.
I had a think over the weekend, using @yannCI’s suggestion for the “Only build pull requests” feature, and I think I’ve come to a solution that works for me.
Using “Only build pull requests” allows Circle to run workflows when a PR is opened, and whenever commits are made to branches referenced in that PR. This works well for running tests against PRs before merging to develop, and also the PR we create before merging to master. What it leaves behind is the ability to run my other workflows to create builds after the tests have succeeded, and to solve that I looked to the tag filtering options.
Using a naming scheme, like dev-YYYY-mm-dd_HH-MM for tags allows us to specify regular expressions in the tag filters for workflows. So to trigger a dev build, we simply push a new tag with the dev- name, and then Circle will run that workflow. Combined with the tests running on PRs mentioned above, this solves the issues I had.