testing

Testing tools, testing philosophy & methodology...
2016-07-25T13:37:43.000014Z

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

2016-07-25T13:38:40.000015Z

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

2016-07-25T14:34:31.000016Z

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

2016-07-25T14:35:34.000017Z

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

2016-07-25T14:35:43.000018Z

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

dominicm 2016-07-25T14:53:39.000019Z

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

2016-07-25T14:59:27.000020Z

right

2016-07-25T15:01:14.000021Z

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'

dottedmag 2016-07-25T15:39:00.000022Z

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

dottedmag 2016-07-25T15:39:10.000024Z

It's not as horrible as Jenkins :)

2016-07-25T18:36:51.000025Z

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

2016-07-25T18:58:19.000026Z

yeah, exactly, that's pretty annoying