This removes non-required dependencies from CI steps in the interest of maximizing the chances for parallelization and receive feedback faster.
For example, we no longer wait for unit tests and linter to finish before building the JS bundle or running the E2E tests. Obviously, required dependencies such as building the JS bundle before building the XCFramework are still in place.
The assumption is that faster feedback is more valuable than the cost of running unnecessary steps.
If the unit tests fail, running the E2E tests is a waste because we know there's something wrong in the code. But the value we get in faster feedback on the whole build is higher than the compute dollars we waste on those steps.
Besides, running the E2E tests even when the UI tests fail might still be valuable. If the E2E pass, for example, we have a signal on a different degree of coverage, which is something worth investigating (but not necessarily, we don't want to replicate the fast, comprehensive coverage that unit tests offer in the slower and more cumbersome E2E layer).
If this approach is considered valuable, we might want to further refine it so that we maybe try to build (or whatever the equivalent in React Native land is of what iOS and Android call building) before attempting tests. That is because if the code doesn't "build," then the problem is upstream of the tests runtime and we know for certain that all those steps will
fail.
Before
After
As can be seen in the images, none of the steps take the same time to run (+/– networking speed affecting resource downloads) but because we start various steps sooner, the whole pipeline completes ~15 minutes earlier.
This removes non-required dependencies from CI steps in the interest of maximizing the chances for parallelization and receive feedback faster.
For example, we no longer wait for unit tests and linter to finish before building the JS bundle or running the E2E tests. Obviously, required dependencies such as building the JS bundle before building the XCFramework are still in place.
The assumption is that faster feedback is more valuable than the cost of running unnecessary steps.
If the unit tests fail, running the E2E tests is a waste because we know there's something wrong in the code. But the value we get in faster feedback on the whole build is higher than the compute dollars we waste on those steps.
Besides, running the E2E tests even when the UI tests fail might still be valuable. If the E2E pass, for example, we have a signal on a different degree of coverage, which is something worth investigating (but not necessarily, we don't want to replicate the fast, comprehensive coverage that unit tests offer in the slower and more cumbersome E2E layer).
If this approach is considered valuable, we might want to further refine it so that we maybe try to build (or whatever the equivalent in React Native land is of what iOS and Android call building) before attempting tests. That is because if the code doesn't "build," then the problem is upstream of the tests runtime and we know for certain that all those steps will fail.
Before
After
As can be seen in the images, none of the steps take the same time to run (+/– networking speed affecting resource downloads) but because we start various steps sooner, the whole pipeline completes ~15 minutes earlier.