Use setup-test-env-patterns for MRs and master alike
Context
corrective action for gitlab-org/quality/engineering-productivity/master-broken-incidents#5850 (closed).
Below is the discussion we had in Slack leading to this MR:
I actually tested that scenario in a test MR (https://gitlab.com/gitlab-org/gitlab/-/pipelines/1247590207 - commit), but apparently it wasn’t enough. I don’t like changing CI rules precisely because of those issues.
I think the problem was that for MRs, setup-test-env runs for upon backend-patterns, but not in master where it uses setup-test-env-patterns. I'm wondering why we have the distinction actually.
We could be safer and replace
.rails:rules:setup-test-env:
rules:
- if: '$ENABLE_RSPEC == "true"'
- <<: *if-default-refs
changes: *setup-test-env-patterns
- <<: *if-merge-request-labels-run-all-rspec
- <<: *if-merge-request
changes: *backend-patterns
with
.rails:rules:setup-test-env:
rules:
- if: '$ENABLE_RSPEC == "true"'
- <<: *if-default-refs
changes: *setup-test-env-patterns
- <<: *if-merge-request-labels-run-all-rspec
With these rules, your test MR would have failed.
What does this MR do and why?
Use setup-test-env-patterns for MRs and master alike
We used to run the setup-test-env CI job differently in
merge requests and on master. The former used the backend-patterns,
and the latter used setup-test-env-patterns.
This commit ensures both use setup-test-env-patterns.
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.