Context: I have about ~100 test suites with a total of ~600 tests (which contain asynchronous tests as well as synchronous tests). I'm using yarn test --coverage to run the tests and generate a coverage report, and when executing this command locally all of the tests pass (and the coverage report is created) as expected.
However, I'm attempting to generate a test coverage report in a Github Action in order to upload the coverage report to a code coverage tool for analysis. To do this, I'm running yarn test --coverage in the Github Action. When executing this command in the Github Action, it has failed 100% of the time (with 2-3 specific tests always being the cause for the failure). For reference, this is my Github Action:
name: Example Action
on:
pull_request:
types: [opened, reopened, synchronize]
push:
branches:
- main
jobs:
nodejs:
name: Example Action
runs-on: ubuntu-latest
timeout-minutes: 20
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Set Node Version
uses: actions/setup-node@v2
with:
node-version: 12
- name: yarn install
run: yarn install
- name: yarn coverage
run: yarn test --coverage
I investigated into why this would happen and realized that it could possibly be due to the "low-resources" available on the machine running the Github Action. In other words, since the container running the Github Action has fewer cores to work with, it seems like Jest is only allowing 1 worker thread to be spawned (as opposed to the many threads that would be spawned locally to run the tests). To test if this was possibly the issue, I ran yarn test --coverage --maxWorkers=1 locally, and as I expected the same tests that were failing on the Github Action were now failing locally (however now it was only 1-2 tests failing of the original 2-3 tests, depending on the run).
My question is, why would the number of threads being used by Jest effect the passing/failing of a test? And also, does anyone have any guidance on any way to investigate/fix this issue?