4 ms·
I think what they meant is that at the pace they were committing coffee to production, the e2e suite would never stop running. This is the most charitable inte
by AmpsterMan 5y ago
I think what they meant is that at the pace they were committing coffee to production, the e2e suite would never stop running.
This is the most charitable interpretation.
- alex-freire 5y agoyou’re right sir!
- joshribakoff 5y agoThe way we solve that at Brex it scales logarithmically, we use bors merge bot which batches everyone’s PRs together and will binary search for the offending PR if any build fails. I’ve hardly ever waited longer than 2x the length our suite takes. They could also decouple CI and only run code tests for upstream changes, so it wasn’t obvious what they meant, thanks for clarifying one theory. I’m not sure I’d agree that it’s a problem with e2e tests per se but rather the problem is slowness itself, and monolithic CI. Not doing e2e tests can be a valid tradeoff to avoid slowness but I’d also point out these issues can be solved without deleting the e2e suite…