Skip to content

Use setup-test-env-patterns for MRs and master alike

David Dieulivol requested to merge ci-setup_test_env_rules_in_MRs into master

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.

Edited by David Dieulivol

Merge request reports