Paginate shared runners in project CI/CD settings
Summary
Similar to #31159 (closed) and #267028 (closed), we should paginate the shared runners on a projects CI/CD Settings page to prevent slow loading and increase responsiveness of this page. If a GitLab instance has a large number of Runners such as 80,000, this would cause the page to timeout and cause 500
s.
Steps to reproduce
- Add a large number of shared runners (our customer had 89,000 runners unintentionally)
- Attempt to load
<group>/<project>/-/settings/ci_cd
and observe the slow performance, or a500
error.
Example Project
See ZD Ticket: https://gitlab.zendesk.com/agent/tickets/270124
What is the current bug behavior?
<group>/<project>/-/settings/ci_cd
takes a very long time to load or returns a 500
if there is a large number of shared runners.
What is the expected correct behavior?
<group>/<project>/-/settings/ci_cd
should be speedier to load and shared runners are paginated.
Relevant logs and/or screenshots
"exception.class": "Rack::Timeout::RequestTimeoutException",
"exception.message": "Request ran for longer than 60000ms",
"exception.backtrace": [
"lib/gitlab/instrumentation/redis_interceptor.rb:61:in `read'",
"lib/gitlab/instrumentation/redis_interceptor.rb:26:in `call'",
"app/models/concerns/redis_cacheable.rb:45:in `block (2 levels) in cached_attributes'",
"lib/gitlab/redis/wrapper.rb:23:in `block in with'",
"lib/gitlab/redis/wrapper.rb:23:in `with'",
"app/models/concerns/redis_cacheable.rb:44:in `block in cached_attributes'",
"lib/gitlab/utils/strong_memoize.rb:30:in `strong_memoize'",
"app/models/concerns/redis_cacheable.rb:43:in `cached_attributes'",
"app/models/concerns/redis_cacheable.rb:24:in `cached_attribute'",
"app/models/concerns/redis_cacheable.rb:17:in `block (2 levels) in cached_attr_reader'",
"app/models/ci/runner.rb:269:in `status'",
...
"ee/app/views/projects/settings/ci_cd/show.html.haml:1",
Output of checks
This happens on GitLab.com
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)
Possible fixes
Similar work was done in !45830 (merged)