chore: split test jobs into stages #2636
Conversation
The current test stage uses _all_ the workers we have available in Travis and starves other projects from running their tests. This change separates interop, externals and examples into stages that only execute if the previous was successful. This means that we use fewer workers concurrently and fewer workers overall since a failure in the main tests will not process and run interop/externals and examples tests. This is at the expense of slower overall CI. License: MIT Signed-off-by: Alan Shaw <[email protected]>
|
Assuming zero flaky tests this will extend CI time to almost two hours (sum of the longest build time in each stage) which starts to impede how many builds we can do in a day. We really need to make our tests faster! |
We got an @hugomrdias working on just that! :D #2276 |
|
Perhaps limiting concurrent jobs is a better option? https://docs.travis-ci.com/user/customizing-the-build/#limiting-concurrent-jobs |
|
I've limited to 20, so that there's always at least 5 workers available to service other projects. |
|
Closing this for now. @daviddias please shout if you still feel js-ipfs is still not being a good CI citizen. |
|
I'll avoid policing and let the team find the optimal point on ways it share the CI. My only remarks are:
Remarks said, as long as the current situation works for everyone, this doesn't feel urgent, so prioritize accordingly :) |
The current test stage uses all the workers we have available in Travis and starves other projects from running their tests. This change separates interop, externals and examples into stages that only execute if the previous was successful. This means that we use fewer workers concurrently and fewer workers overall since a failure in the main tests will not process and run interop/externals and examples tests. This is at the expense of slower overall CI.