Fork me on GitHub
#testing
<
2016-07-25
>
Al Baker13:07:43

lmergen will do - we've used Snap CI, but their builds will often terminate early for no reason on our side, and they seem to refuse to fix it - "just run another one", not great for very large projects that take an hour to build

Al Baker13:07:40

I emailed circle CI, which mentions scale in their website description but I don't see any explicit features like pick your EC2 type or something

lmergen14:07:31

yes, that's a common attitude. seems like these CI tools optimize for the 80% case, but that leaves us with a pretty annoying problem

lmergen14:07:34

anyway, i'm trying to figure something out that uses AWS lambda, or another way to parallelize

lmergen14:07:43

because that appears to be the only sane way to do this

dominicm14:07:39

Everything optimizes for the 80% case I think, and eventually everything dips into the 20% cases of a domain

lmergen15:07:14

out of curiousity, what do your integration test times (i.e., git clone and lein test) look like ? for us right now, one of our biggest projects is at +- 20 minutes, and it starts to become a problem when many people are working on that code -- for which the only solution would be 'throw money at travis'

dottedmag15:07:00

I'd go with on-premises CI in this case, e.g. http://concourse.ci

dottedmag15:07:10

It's not as horrible as Jenkins :)

Al Baker18:07:51

lmergen: circleci enterprise has a large instance, but no different types -- our builds are 1hour+

lmergen18:07:19

yeah, exactly, that's pretty annoying