Currently, tests take up an enormous amount of time of the CI workflow. On average, from 2 hours of the workflow they consume almost 3/4 of this time. The reason, initially, all tests were written for executing in separated repositories where, individually, tests didn't take up a lot of time but now, in a single workspace, this has become very critical. Therefore, we need to somehow reduce the time for tests.
Here are some ideas:
- Analyze, rewrite & reduce the number of tests up to the most necessary
The most time consuming tests use gclient. Some of them didn't need it all, and can be rewritten with gtest. Also, some tests are implemented for high load testing and as well take a long time. They can be moved to a separate manually controlled CI workflow or can be simply ignored by the main workflow.
- Use a custom node binary optimized for a faster execution
Right now we use the node binary from the official builds. By default, it's using a configuration close to one on the public net. Perhaps there can be some flags or we can modify node's internals to speed it up. Of course, security consideration must be taken to make sure that the custom node won't suppress any bugs that later may be found in the default node.
- Put all tests for into one file in each workspace member
This'll degrade readability but may reduce the execution time because tests in one file are executed in parallel.
Currently, tests take up an enormous amount of time of the CI workflow. On average, from 2 hours of the workflow they consume almost 3/4 of this time. The reason, initially, all tests were written for executing in separated repositories where, individually, tests didn't take up a lot of time but now, in a single workspace, this has become very critical. Therefore, we need to somehow reduce the time for tests.
Here are some ideas:
The most time consuming tests use
gclient. Some of them didn't need it all, and can be rewritten withgtest. Also, some tests are implemented for high load testing and as well take a long time. They can be moved to a separate manually controlled CI workflow or can be simply ignored by the main workflow.Right now we use the node binary from the official builds. By default, it's using a configuration close to one on the public net. Perhaps there can be some flags or we can modify node's internals to speed it up. Of course, security consideration must be taken to make sure that the custom node won't suppress any bugs that later may be found in the default node.
This'll degrade readability but may reduce the execution time because tests in one file are executed in parallel.