[somesaba]

Cool! I had an idea for something like this but instead of having each build be it's own lambda event, I wanted to make each individual test it's own lambda event. The goal is to have the build time for a complex project boil down to the time it takes to setup + run the longest test.

[adamb]

Have you written any code to that effect? I've been trying to think through how booting up dependencies might work (for things like integration tests).

I have aspirations for QA (https://github.com/ajbouh/qa) to learn this trick, but it needs some lambda-specific smarts before it gets there.

[falsedan]

We're doing something similar, but using mesos. We bundle tests up, so we don't have to eat the setup costs for every test, and try tracking test pollution by splitting bundles when they fail & running them separately, again.

[not_yet_a_dalek]

That is more or less the same reason I started the eremetic framework. We were tired of dealing with the trouble of using a lot of VMs as jenkins-slaves, and long test suite runtimes.

https://github.com/klarna/eremetic

[dominotw]

where do you store build caches? npm/gems ect?

[falsedan]

Dependencies? On the host; they're ephemeral but they'll run multiple builds between coming into existence and disappearing.

[dominotw]

but first build always take a hit making the build times unpredictable making build time regressions hard to track.

[rapind]

I love that idea. Map -> Reduce of unit tests.