Skip to content

Do not `eager_load` by default in the test environment

What does this MR do and why?

Usually, developers run a single test locally. Disabling eager loading by default in test environment should increase productivity since it saves around 10 seconds:

With eager_load as true:

bogdanvlviv@lenovo:~/gitlab-development-kit/gitlab$ bin/rspec spec/models/users_statistics_spec.rb
Run options: include {:focus=>true}

All examples were filtered out; ignoring {:focus=>true}

Test environment set up in 5.122837013 seconds
......

Finished in 8.51 seconds (files took 16.46 seconds to load)
6 examples, 0 failures

With eager_load as false:

bogdanvlviv@lenovo:~/gitlab-development-kit/gitlab$ bin/rspec spec/models/users_statistics_spec.rb
Run options: include {:focus=>true}

All examples were filtered out; ignoring {:focus=>true}

Test environment set up in 5.013345478 seconds
......

Finished in 8.24 seconds (files took 7.18 seconds to load)
6 examples, 0 failures

Inspired by https://github.com/rails/rails/pull/43508.

It is important to eager load app before deploying it to catch any issues with constants loading. I see that we disable eager_loading on CI, !30368 (diffs) For the mentioned reason above I think we should enable eager loading on CI. @rymai What do you think about that?

I also found that we 'Speed up backend tests in Gitpod environment', !68482 (merged). /cc @splattael

Remove GITLAB_TEST_EAGER_LOAD: "0" for scripts/setup-test-env It doesn't make any difference for this script. See !72964 (comment 713013642)

Document GITLAB_TEST_EAGER_LOAD. Closes #343751 (closed)

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Contributes to #255339 (closed)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Peter Leitzen

Merge request reports