5 ms·

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 eve

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 10y ago
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 https://github.com/ajbouh/qa) to learn this trick, but it needs some lambda-specific smarts before it gets there.
rapind 10y ago
I love that idea. Map -> Reduce of unit tests.
falsedan 10y ago
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.
- dominotw 10y ago
  where do you store build caches? npm/gems ect?
  - falsedan 10y ago
    Dependencies? On the host; they're ephemeral but they'll run multiple builds between coming into existence and disappearing.
    - dominotw 10y ago
      but first build always take a hit making the build times unpredictable making build time regressions hard to track.
- not_yet_a_dalek 10y ago
  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 https://github.com/klarna/eremetic