Fixes flaky specs in email participants feature specs
What does this MR do and why?
Solves FOSS master broken: ./spec/features/projects/is... (#428361 - closed)
Contributes to those broken master pipelines
- gitlab-org/release/tasks#6846 (closed)
- gitlab-org/release/tasks#6869 (closed)
- gitlab-org/quality/engineering-productivity/master-broken-incidents#3883 (closed)
- gitlab-org/release/tasks#6911 (closed)
- gitlab-org/quality/engineering-productivity/master-broken-incidents#3902 (closed)
- gitlab-org/release/tasks#6925 (closed)
- gitlab-org/release/tasks#6925 (closed)
- gitlab-org/release/tasks#6927 (closed)
- gitlab-org/release/tasks#6928 (closed)
- gitlab-org/release/tasks#6930 (closed)
- gitlab-org/quality/engineering-productivity/master-broken-incidents#3912 (closed)
- gitlab-org/release/tasks#6932 (closed)
- gitlab-org/quality/engineering-productivity/master-broken-incidents#3915 (closed)
- gitlab-org/quality/engineering-productivity/master-broken-incidents#3916 (closed)
- gitlab-org/quality/engineering-productivity/master-broken-incidents#3917 (closed)
We saw this for the first time 5 days ago. We use let_it_be and change an issues confidentiality in one spec. Other specs cannot access the issue then.
I added dedicated records for the confidentiality specs, so we only create two rounds of records for the whole file instead of a bunch more if we'd use let!.
Screenshots or screen recordings
How to set up and validate locally
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Marc Saleiko