Fix Pages object storage validation under consolidated config
What does this MR do?
Fix Pages object storage validation under consolidated config
The gitlab.checkConfig.objectStorage.pages.configured check required a
per-Pages connection whenever Pages and its object storage were enabled,
regardless of whether consolidated object storage was in use. In
consolidated mode Pages inherits the shared object_store.connection and
its per-Pages connection is never rendered, so a valid default setup was
incorrectly failing the install with a request to configure a connection
that the templates ignore.
Guard the check so a per-Pages connection is only required when
consolidated object storage is disabled. Also extend the consolidated
mixing detection to flag global.pages.objectStore.connection (and an
empty bucket), matching how the other object storage types are validated,
so a silently-ignored Pages connection no longer slips through.
Update the test defaults to drop the now-unnecessary Pages connection (which would otherwise trip the new mixing detection) and add specs covering both the consolidated and type-specific branches.
Also I discovered gitlab-pages does not require the object credentials, so we can remove the Secret mount for the gitlab-pages Pod.
Closes: #6531 (closed)
Changelog: fixed
Related issues
Author checklist
For general guidance, please follow our Contributing guide.
Required
For anything in this list which will not be completed, please provide a reason in the MR discussion.
- Merge Request Title and Description are up to date, accurate, and descriptive.
- MR targeting the appropriate branch.
- MR has a green pipeline.
- Documentation created/updated.
- Tests added/updated, and test plan for scenarios not covered by automated tests.
- Equivalent MR/issue for omnibus-gitlab opened.
Reviewers checklist
- MR has a green pipeline on https://gitlab.com/gitlab-org/charts/gitlab.
- Consider downstream impact to the Operator, as per evaluating impact from changes to GitLab chart.