Paginate the section for deploy keys in project settings
Summary
One of our customers reported that going to project's Settings > Repository > Deploy Keys
section on any project takes nearly a minute to load, and most often times out. According to them they have 5000 deploy keys configured for the project.
Based on my tests, we will try to load all deploy keys in the page, which is the reason for the slow down.
I was able to reproduce this on the latest version of GitLab.
Steps to reproduce
- Create a project.
- Load at least 2000 deploy keys
- Try to access the project's
Settings > Repository > Deploy Keys
section
What is the current bug behavior?
The page loads slowly as GitLab will try to load all deploy keys in the page.
What is the expected correct behavior?
GitLab should paginate it to increase the performance.
Relevant logs and/or screenshots
Output of checks
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
- Add a Default Pagenation Component to the list of keys, and show max 20 keys per page.
Mockup |
---|
Note, the mockup only shows 10 per page for ease of viewing concept together.
Technical Proposal
- Create a feature flag:
deploy_keys_pagination
- Update the deploy keys controller to create new actions for each tab in the frontend and paginate the response
- Update the deploy key table to request each scope separately on demand instead of up front.