Assess whether or not to keep default entries on .com settings page
In !75117 (comment 748929291), @10io made a good point, that we are duplicating some instance default values on the .com settings page, so we don't have a SSoT.
For example, we have https://docs.gitlab.com/ee/user/gitlab_com/#package-registry-limits, which duplicates the defaults on the self-managed limits page https://docs.gitlab.com/ee/administration/instance_limits.html#package-registry-limits
If a self-managed setting changes, we need to update it in both the admin pages and the .com settings page, despite it not affecting .com. It makes sense to remove the defaults from that page, and link back to the SSoT for each setting, when possible.
We should review the following sections, find out where the instance defaults are documented, and link to those defaults instead of duplicating them here. If they are not documented anywhere, we should find a place in the admin docs and move them there.
Sections to review:
-
https://docs.gitlab.com/ee/user/gitlab_com/#gitlab-pages - groupknowledge ( @ashrafkhamis
) -
https://docs.gitlab.com/ee/user/gitlab_com/#gitlab-cicd - grouppipeline authoring grouppipeline execution grouptesting -
https://docs.gitlab.com/ee/user/gitlab_com/#package-registry-limits - ~"group::package" -
https://docs.gitlab.com/ee/user/gitlab_com/#account-and-limit-settings - ~"group::import" (and groupsource code I think?) -
https://docs.gitlab.com/ee/user/gitlab_com/#webhooks - ~"group::integrations" -
https://docs.gitlab.com/ee/user/gitlab_com/#sidekiq - ~"group::application performance" ( @jglassman1
) -
https://docs.gitlab.com/ee/user/gitlab_com/#postgresql - groupdatabase ( @aqualls
)