Skip to content

ci: Always run full Jest specs after approval

Nao Hashizume requested to merge 379174-run-full-jest-when-approved into master

What does this MR do and why?

Previously, selective Jest jobs ran before and after approvals, with pipeline:run-all-jest label available to override for running full Jest jobs. However, some of recent master broken issues indicate that selective Jest jobs have some test gap, which have been identified when only selective Jest jobs ran and full Jest jobs ran in master.

We should consider running full Jest jobs after approvals until this test gap is identified and addressed.

This MR introduces changes to:

  • Run jest full job after the MR is approved instead of jest minimal in MR pipelines.
  • Run jest as-if-foss job after the MR is approved and the MR has frontend-patterns-for-as-if-foss changes.

Closes #379174 (closed)

This conceptually reverts !97552 (merged)

Testing

Tested this CI configuration changes in !103559 (closed).

Code changes Which changes pattern is satisfied? Approved? Result
config/routes/admin.rb code-backstage-patterns Yes jest and jest-integration are created: https://gitlab.com/gitlab-org/gitlab/-/pipelines/694458216
config/routes/admin.rb code-backstage-patterns No jest minmal and jest integration are created: https://gitlab.com/gitlab-org/gitlab/-/pipelines/694455982
config/helpers/is_ee_env.js frontend-patterns-for-as-if-foss Yes jest, jest integration, and jest as-if-foss are created: https://gitlab.com/gitlab-org/gitlab/-/pipelines/694436650

I've tested these scenarios by applying ~"pipeline:run-full-rspec" label to the test MR to simulate the pipeline is approved, since if-merge-request-approved condition checks if the MR has ~"pipeline:run-full-rspec" set.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Lin Jen-Shin

Merge request reports

Loading