Jest coverage improvements in CI
What does this MR do and why?
Ignore generated i18n files for jest code coverage
This should have no big impact in CI, but has some locally. It just makes no sense to generate the coverage for these.
Use less jest coverage reporters in CI
When we use parallel runners in CI, we merge the results of the code
coverage with: scripts/frontend/merge_coverage_frontend.js afterwards.
The merge script is able to produce other formats out of the JSON, so
we don't need to generate thousands of HTML files for the lcov format.
Do not collect all coverage in MR pipelines
Collecting coverage for all files, rather than just tested files seems
rather expensive. Let's only do that on master.
Run baseline coverage detection in the last shard
As opposed to making a distinction between MRs and the default branch. The technique is rather simple. Imagine we have 10 shards.
- Chunk the specs into 9 shards.
- have the tenth shard only run one spec file and collect coverage from all files.
Use the CI_JOB_NAME_SLUG for naming the coverage folder
Because we now have different job names for jest jobs, and we could run into naming collisions.
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
N/A
How to set up and validate locally
N/A