Add support for container registry detabase prefer mode
What does this MR do?
Add support for container registry detabase prefer mode
feat(registry): Add database prefer mode with PostgreSQL detection
Implement support for Container Registry's database.enabled prefer mode by adding runtime detection of PostgreSQL source (subchart vs external).
This ensures migrations and database configuration only occur when the registry database is guaranteed to exist:
- With PostgreSQL subchart: database auto-created, migrations run
- With external PostgreSQL + prefer: migrations skipped unless database.configure=true is set
Changes:
- Usages of the
registry.database.enablednow support bool or string. This is necessary to support 'prefer|true|false'. We kept bool for backward compatibility. - Add shared-data ConfigMap to communicate PostgreSQL subchart status
- Update registry deployment to mount shared-data ConfigMap (optional)
- Add init script logic to set database.enabled based on PostgreSQL source
- Update migrations job to skip when database may not exist
- Maintain backward compatibility with existing configurations
The shared-data ConfigMap uses an extensible design to support future cross-subchart communication needs without global value dependencies.
Registry migrations WILL run:
- database.enabled = true with embedded PostgreSQL
- database.enabled = true with external PostgreSQL
- database.enabled = 'prefer' with embedded PostgreSQL - New prefer mode
Registry migrations WON'T run:
- database.enabled = false - Database disabled explicitly on that node
- database.enabled = 'prefer' with external PostgreSQL - Can't safely run migrations without GitLab-managed DB. Also on Multi-node, we can't be sure that the GitLab-managed DB was deployed as the registry might be running on a separate node then PostgreSQL, so the migrations won't automatically run unless explicitly configured by the user.
Changelog: added
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.