## Problem The CI/CD settings page will error out with `503` status if the project or group has a significant amount of environments or CI variables to load. This epic collates all issues related to solving this issue. The goal is to improve the CI Variables settings experience and reduce the load when requesting variables and environments data from the API. ### Links See https://gitlab.com/gitlab-org/gitlab/-/issues/380873+ for context. See [here](https://gitlab.com/gitlab-data/product-analytics/-/issues/929#note_1321275080) for the data analysis. > The analysis above supports the idea that namespaces and projects who experience 503 errors have a higher number of environment compared to the macroenvironment of GitLab.com. Despite only comprising 0.014% of total projects within GitLab.com, we see 235% more environments used from projects with a 503 error, with the 90th Percentile of projects increasing from 6 environments to 29 environments when a project has a 503 error. When we look at projects that also use custom variables, we see that 90th Percentile jump to 39 environments when they have projects that also utilize custom variables. > > When looking at group namespaces that utilize scoped variables, we see an average of 95 scoped variables used per namespace and will utilize at least 44 environments per namespace when using scoped variables. The number of environments per group namespace gets even higher when a namespace experiences a 503 error - the average number of environments jumps to 57 environments used when a namespace has scoped variables and experiences a 503 error and the 90th percentile of that same group will use at least 62 environments. This indicates that we do have a higher number of environments, variables, and scoped variables utilized when a namespace or project experiences a 503 error. > > A nominal percentage of projects and namespaces will experience a 503 error, with 0.014% of projects of 0.09% of namespaces experiencing a 503 error. If the goal is to limit when the error occurs, I believe that the number of variables and environments shown should match at least the 90th Percentile of each category as this would be the majority of each population. **For variables, the 90th Percentile of projects and namespaces will use anywhere between 10 - 25 variables. For environments, I believe that loading at least 30 environments (since the 90th Percentile of projects with 503 environments will use 29 environments) will help reduce the number of 503 errors that occur.** ## Solutions There are two solutions outlined here: - Environments dropdown query should fetch and search the API for a maximum of 20 environments per request. This applies to the project settings (already has its own query) and group settings (doesn't have its own query yet). Setting for CI Variables does not have an environments dropdown. This is developed under the `ci_limit_environment_scope` feature flag. - Paginate CI Variables. This is developed under the `ci_variables_pages` feature flag. Improvements to the environments dropdown is required before continuing development for pagination. In order to move forward with this epic, we also need to implement the search functionality. See https://gitlab.com/groups/gitlab-org/-/epics/10086#note_1496128657.