Speed up specs by stubbing Kernel#sleep calls
What does this MR do and why?
This MRs improves RSpec runtime (16s -> 11s) by stubbing Kernel#sleep
.
Comparison
Before
$ hyperfine "bundle exec rspec"
Benchmark 1: bundle exec rspec
Time (mean ± σ): 16.126 s ± 1.729 s [User: 8.919 s, System: 0.740 s]
Range (min … max): 13.226 s … 18.597 s 10 runs
Top 10 slowest examples (8.41 seconds, 57.7% of total time):
Triage::AssignComplianceDevForVerification#process when issue is closed does not assign dev
2.99 seconds ./spec/processor/compliance_group/assign_dev_for_verification_spec.rb:150
Triage::AssignDevForVerification#process when issue is closed does not assign dev
2.14 seconds ./spec/processor/assign_dev_for_verification_spec.rb:184
Triage::AssignDevForVerification#process when there is assignee does not assign dev
2.04 seconds ./spec/processor/assign_dev_for_verification_spec.rb:168
Triage::PercentageRollout with processors having percentage roll out processes the given percentages of events
0.3017 seconds ./spec/triage/percentage_rollout_spec.rb:78
TeeStream.exec captures command status, output and error streams
0.24002 seconds ./spec/lib/tee_stream_spec.rb:21
TeeStream.exec writes command stdout and stderr to provided streams
0.23925 seconds ./spec/lib/tee_stream_spec.rb:32
Triage::CommandMrUnassignReview#applicable? behaves like rate limited does not post a comment if number of commands sent exceeds the allowed limit within the period
0.12389 seconds ./spec/support/rate_limit_shared_examples.rb:4
Triage::CommandMrRequestReview#applicable? when actor is a team member behaves like rate limited does not post a comment if number of commands sent exceeds the allowed limit within the period
0.1192 seconds ./spec/support/rate_limit_shared_examples.rb:4
Triage::KeepCacheWarmJob#perform_async when refreshing raising an error schedules next same job and capture errors
0.1061 seconds ./spec/job/keep_cache_warm_job_spec.rb:71
Triage::KeepCacheWarmJob#perform_async schedules next same job
0.10249 seconds ./spec/job/keep_cache_warm_job_spec.rb:55
After
$ hyperfine "bundle exec rspec"
Benchmark 1: bundle exec rspec
Time (mean ± σ): 11.539 s ± 0.433 s [User: 9.275 s, System: 0.764 s]
Range (min … max): 10.896 s … 12.244 s 10 runs
Top 10 slowest examples (1.66 seconds, 22.9% of total time):
Triage::PercentageRollout with processors having percentage roll out processes the given percentages of events
0.34353 seconds ./spec/triage/percentage_rollout_spec.rb:78
TeeStream.exec writes command stdout and stderr to provided streams
0.24278 seconds ./spec/lib/tee_stream_spec.rb:32
TeeStream.exec captures command status, output and error streams
0.24129 seconds ./spec/lib/tee_stream_spec.rb:21
Triage::CommandRetryPipelineOrJob#process when retrying job behaves like retry pipeline or job behaves like rate limited discussion notes requests does not post a discussion if number of commands sent exceeds the allowed limit within the period
0.19202 seconds ./spec/support/rate_limit_shared_examples.rb:41
Triage::CommandMrUnassignReview#applicable? behaves like rate limited does not post a comment if number of commands sent exceeds the allowed limit within the period
0.12365 seconds ./spec/support/rate_limit_shared_examples.rb:4
Triage::CommandMrRequestReview#applicable? when actor is a team member behaves like rate limited does not post a comment if number of commands sent exceeds the allowed limit within the period
0.11697 seconds ./spec/support/rate_limit_shared_examples.rb:4
Triage::KeepCacheWarmJob#perform_async when refreshing raising an error schedules next same job and capture errors
0.10771 seconds ./spec/job/keep_cache_warm_job_spec.rb:71
Triage::KeepCacheWarmJob#perform_async schedules next same job
0.10258 seconds ./spec/job/keep_cache_warm_job_spec.rb:55
Triage::CommandMrHelp#applicable? when actor is a team member behaves like rate limited does not post a comment if number of commands sent exceeds the allowed limit within the period
0.0939 seconds ./spec/support/rate_limit_shared_examples.rb:4
Triage::CommandMrHandoff#applicable? when actor is a team member behaves like rate limited does not post a comment if number of commands sent exceeds the allowed limit within the period
0.09091 seconds ./spec/support/rate_limit_shared_examples.rb:4
Expected impact & dry-runs
These are strongly recommended to assist reviewers and reduce the time to merge your change.
See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.
See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.
Action items
-
If adding environment variables for reactive processors, update config/triage-web.yaml
and.gitlab/ci/triage-web.yml
-
(If applicable) Add documentation to the handbook pages for Triage Operations => - (If applicable) Identify the affected groups and how to communicate to them:
-
/cc @ person_or_group
=> -
Relevant Slack channels => -
Engineering week-in-review
-
Edited by Peter Leitzen