Use let_it_be to speed up pipeline specs
What does this MR do?
This MR improves the performance of the pipeline feature specs, by using let_it_be to create projects.
This work has no issue and was just some low-hanging fruit that I noticed while I was working on another issue.
Result Summary:
- Total projects created: 103 -> 30
- Total time creating projects: 21.9884s -> 7.8286s
Before:
[TEST PROF INFO] Factories usage
Total: 1138
Total top-level: 923
Total time: 50.8896s
Total uniq factories: 17
total top-level total time time per call top-level time name
478 478 13.8186s 0.0289s 13.8186s ci_build
146 100 7.2753s 0.0498s 5.0425s user
104 92 3.9471s 0.0380s 2.6711s ci_pipeline
103 97 21.9884s 0.2135s 20.9686s project
101 0 5.2987s 0.0525s 0.0000s namespace
73 73 2.2197s 0.0304s 2.2197s generic_commit_status
48 0 0.1999s 0.0042s 0.0000s namespace_settings
48 48 1.8531s 0.0386s 1.8531s group
12 12 3.8711s 0.3226s 3.8711s merge_request
10 10 0.0829s 0.0083s 0.0829s ci_resource_group
6 6 0.1207s 0.0201s 0.1207s ci_bridge
2 0 0.1285s 0.0643s 0.0000s ci_job_artifact
2 2 0.0398s 0.0199s 0.0398s ci_empty_pipeline
2 2 0.1181s 0.0590s 0.1181s ci_pipeline_schedule
1 1 0.0498s 0.0498s 0.0498s protected_branch
1 1 0.0101s 0.0101s 0.0101s user_status
1 1 0.0234s 0.0234s 0.0234s licenseAfter:
Total time: 38.9015s
Total uniq factories: 17
total top-level total time time per call top-level time name
466 466 15.8400s 0.0340s 15.8400s ci_build
104 98 5.9978s 0.0577s 5.6367s user
102 90 4.8177s 0.0472s 3.1602s ci_pipeline
71 71 2.5102s 0.0354s 2.5102s generic_commit_status
30 24 7.8286s 0.2610s 6.5101s project
28 0 1.8160s 0.0649s 0.0000s namespace
12 12 4.5204s 0.3767s 4.5204s merge_request
10 10 0.1040s 0.0104s 0.1040s ci_resource_group
6 6 0.1498s 0.0250s 0.1498s ci_bridge
3 0 0.0179s 0.0060s 0.0000s namespace_settings
3 3 0.1607s 0.0536s 0.1607s group
2 0 0.1870s 0.0935s 0.0000s ci_job_artifact
2 2 0.0541s 0.0271s 0.0541s ci_empty_pipeline
2 2 0.1730s 0.0865s 0.1730s ci_pipeline_schedule
1 1 0.0599s 0.0599s 0.0599s protected_branch
1 1 0.0117s 0.0117s 0.0117s user_status
1 1 0.0106s 0.0106s 0.0106s licenseScreenshots or Screencasts (strongly suggested)
Does this MR meet the acceptance criteria?
Conformity
-
I have included changelog trailers, or none are needed. (Does this MR need a changelog?) - [-] I have added/updated documentation, or it's not needed. (Is documentation required?)
- [-] I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
- [-] I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
-
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides. -
This change is backwards compatible across updates, or this does not apply.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) - [-] I have tested this MR in all supported browsers, or it's not needed.
- [-] I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Security
Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.
- [-] Label as security and @ mention
@gitlab-com/gl-security/appsec - [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [-] Security reports checked/validated by a reviewer from the AppSec team
Edited by Allison Browne