For example, suppose that I have following branches,
dev-branch (default branch)
prod-branch
random-branch
trying-to-make-sense-branch
and I have my own fork of this repository, with following additional branches,
important-feature-branch
beautiful-feature-branch
and now, I send a PR from important-feature-branch to dev-branch.
I want to build this PR, and dev-branch, and prod-branch.
However, I cannot find a way to do this.
If I turn Only build pull requests setting on, CircleCI will not build prod-branch (which is not a default branch),
If I set workflows[<workflow name>].jobs[<job name>].filters.branches.only to
- dev-branch
- prod-branch
, job does not start with PRs.
Is there any way to resolve this situation? (a way to execute jobs in workflow for each commits of some branches and all PRs to those branches)
Same here, looking for alternatives to do something similar via CircleCI without turning to a “hacky” solution: for now what I’ve done is to open a PR from prod-branch to a dummy branch, and block that PR from being merged. But this is less than ideal since that means that for prod-branch to be deployed there has to be a permanent opened PR.
Same here. For libraries that support multiple branches (not only master), it would be interesting to get the same behavior for all supported branches, without losing the ability to run builds on PRs too.
I also need this. It isn’t very intuitive that opening a pull request to master behaves as expected, but opening a pull request in to any other branch does not.
Second this. Something similar would be to allow building for all PRs and their merged results. With the current setting, it is very hard to run a deploy job for a staging branch. If I want to deploy the staging branch, I need to open a PR to merge to master and then abandon it.
All in the negative:
If CIRCLE_PULL_REQUESTS is empty (it’s not a PR) and $CIRCLE_BRANCH doesn’t match (grep -v) this regex for my branches then echo that we won’t build and halt the step
Above works for any PR and branches that match the regex (branches “master” “release” and anything starting with “build/”). So changing the regex one could configure this to match any branches that one wants to build.
The rest of the steps continue below to checkout the code and run tests.
Note: this has the effect that a circleci build always runs. And, if it doesn’t match, then it stops at the first step, and the build is “success”. What doesn’t run is anything after the first step.
If you push a branch with a name not in the regex, and then open a pull request, does that trigger the build?
Not having this feature to build a specific set of branches always, but all PRs, is turning into a pretty major inconvenience for us because of the way things get triggered.
@davidharris You hit the nail on the head. It will not.
Circleci will have built that commit while it was not a PR, does the fast bail. When it becomes a PR, it won’t re-run it, instead showing the previous result (since it is the same commit).
We ended up just building on all commits on all branches to get what we wanted. (So it builds for PRs as well as all branches that we need it to - and all other branches too, which we didn’t care about.) This is sub-optimal, but works. Downside is that it has our CI busier running things we don’t care to test.
At that point I guess we might as well just put everything for PRs on a manual trigger, but that’s quite tedious. Our build and test scheme is very expensive, so we can’t enable it on all branches.
Could you run builds on master and also a special tag trigger? It is possible to limit builds to a set of branches and named tags.
Your workflow in the PR branch would be to add the tag to the head, delete that tag remotely if it exists, and then push the tag with git push --follow-tags. That would be a few lines of Bash scripting, run locally.
Because we’re a mobile flow, we really need a release branch to be stabilized and soaked while it runs through submission processes and we identify the last minute bugs, of which there are always a handful to cherry-pick. Unfortunately the git tag flow won’t work for us well in that case, unless we maybe tag the release branch to trigger builds but I’m not sure that works without a PR (nor do I know if that’s a clean process, since it’s still manual)