Build on PR merge

Build Environment
1

I see posts asking for this since 2015.
Here’s the situation, as I understand things.

We have two options which are mutually exclusive:

  • Run on every commit
  • Run on every PR

There is no way to do both, if I understand correctly?

At our company, we have 3 main branches:

  • master
  • develop
  • release/x.y.z

When a developer does a feature/something_cool branch, it will typically get merged into develop
The following week, develop gets branched into that week’s release/x.y.z
Once that release branch has shipped, it gets merged into master

So, I do want standard unit testing integrations to run when a PR is created for a branch.
But then, once the branch is promoted into develop or release/x.y.z or master (which can happen for cherrypicks, hotfixes, etc…) the receiving branch should run its integration.

If I set Circle to run on every commit, I can filter some branches to shortcircuit (i.e. cancel the job early) if there is no PR URL associated with it. However, once a branch then issues a PR, nothing happens. Creating a PR is not considered a “commit” and Circle does nothing.

If I set Circle to run on every PR, then merging those PRs into their respective branches does nothing because that merge has no PR any longer.

Again, I see people asking about this since 2015, and it seems very odd to me that 6 years later we only have this one-or-the-other solution. Therefore, I have my fingers crossed that there is something I’ve simply overlooked. Some new feature with 2.1 maybe, that lets me unify my commit-based and PR-based workflows. For example, if when: could be used, as when: pr-merged or something? Just spitballing here…

2

It’s late and I may not be following everything you’re saying here but I’m confused on a few points.

  1. You’re saying that if you have your project configured to run on every commit then it doesn’t run your workflow when you merge a PR?

That’s not my experience. I have almost all my projects set up to run on every commit and we also regularly run PRs. Now you’re right in saying that if a commit has already had a run in CCI before a PR the PR doesn’t run it an additional time just because it was created. It does however link to the existing run for you which seems like better behavior? In this sense ‘all commits’ is a strict superset of ‘all PRs’.

  1. You’re saying that if you have ‘all PRs’ selected it doesn’t run when you merge the PR?

That’s also not my experience. I’ve had this setting on a few of my projects and it does what I expect. If I push to a branch that doesn’t have a PR then I don’t get a run but if I push to a branch represented by a PR then I get a run. And on merge of the PR I get a run of the mainline branch.

Ah but then maybe it clicks.

We don’t run with your level of branching. We have short lived branches and mainline. I think CCI always treats mainline specially. In your case you’re saying that you have N special branches, master, develop, and release/x.y.z. And in that case maybe you don’t get the special treatment on those branches if you have CCI run on just PRs?

So really the behavior you’re looking for is to run on just PRs but treat branches other than the main branch as special as well?

One idea as a workaround if that’s the case would be to simply have open PRs for your non-mainline special branches. You’d either need to create them again whenever you merge them in to their respective git flow branches (which is relatively easy to automate) or only merge them partially each time (seems harder really). Then you can kind of have your cake and eat it to.

Another idea is just to go with all commits. The only reason I can think of to go with only PRs is cost saving. Maybe your team commits more than my team does but I feel like unless you’re working at a truly enormous organization you’re probably not saving a lot of money by avoiding running against all commits.

Let me know if I’m missing something. :slight_smile:

3

@timvisher
You talked yourself into understanding, it seems. :smiley:
You have it right; I need more than one “main branch” to trigger a build on PR merge.

We currently do “all commits” and it has been a large bottleneck for our developer productivity.
Granted, we haven’t been using CircleCI, but rather an in-house custom solution, so we didn’t have the level of build concurrency CircleCI provides.
However, infrastructure cost savings is a continuing goal for the company. Reducing the work to just the critical build paths would be quite useful to us.

That said, maybe commit-based will prove to be our only real solution :man_shrugging:
At any rate, I appreciate your feedback and insight.

4

These two quotes together have my quite confused. :slight_smile:

You’re ‘set[ting] Circle’ to do something but you’re not ‘using CircleCI’? That’s quite a trick.

Anyway, I would definitely encourage you to go the route of simply running on every commit everywhere in CCI. One thing that isn’t immediately obvious when coming from a bespoke self-hosted solution is that you’re not paying for downtime. CCI costs (essentially) nothing unless you’re running the build and it’s very simple to have differently workflows configured differently based on different branches. It wouldn’t surprise me if you come out ahead budget wise without any constraints at all.

Good luck! :slight_smile:

1 Like
5

We are migrating from our in-house solution onto CircleCI.
They are running in parallel right now while we see that Circle is working as expected. So “we haven’t been using CircleCI” was meant to say, “we haven’t been using CircleCI until now”

  • Our in-house solution runs “per commit”
  • Our Circle solution runs “per PR”

You may be right about the pricing; I should do some real calculations on estimated costs now that I have working builds on CircleCI to compare against the old server rental costs.

Thanks for your advice!

1 Like