From this blog post:
using the docker executor will often have your job running in a VM with thirty-two CPU cores available. This causes problems with testing tools like jest which by default will spawn workers based on the number of available CPU cores. It will think it has access to thirty-two cores, but in reality, while using a medium resource class, it only has access to two.
To prevent jest tests timing out, limit the number of workers to 2.
Clean up the list of npm scripts. We can now run them all together (change in package.json and circle ci config)
Following advice here the heap size should not grow larger than 3GB available to Gradle.
As it is the Gradle daemon that usually times out, disable it. From this CircleCI blog post: The daemon runs by default and is helpful when running locally as it speeds up recompilation.
This is not needed in continuous integration since every compilation is fresh. It takes up more memory for no benefit.
What this does
From this blog post: using the docker executor will often have your job running in a VM with thirty-two CPU cores available. This causes problems with testing tools like
jest
which by default will spawn workers based on the number of available CPU cores. It will think it has access to thirty-two cores, but in reality, while using a medium resource class, it only has access to two.To prevent jest tests timing out, limit the number of workers to 2.
Clean up the list of npm scripts. We can now run them all together (change in package.json and circle ci config)
Following advice here the heap size should not grow larger than 3GB available to Gradle.
As it is the Gradle daemon that usually times out, disable it. From this CircleCI blog post: The daemon runs by default and is helpful when running locally as it speeds up recompilation. This is not needed in continuous integration since every compilation is fresh. It takes up more memory for no benefit.