## Summary When upgrading to GitLab chart **9.11.0**, the `gitlab-migrations` job aborts during `gitlab:db:configure` with the following error: ``` rake aborted! Object storage for dependency_proxy must have a bucket specified /srv/gitlab/config/object_store_settings.rb:234:in `missing_bucket_for' /srv/gitlab/config/object_store_settings.rb:172:in `block in parse!' /srv/gitlab/config/object_store_settings.rb:161:in `parse!' ``` ## Configuration ```yaml global: appConfig: object_store: enabled: true # consolidated object storage dependencyProxy: enabled: false # dependency proxy object storage disabled bucket: gitlab-dependency-proxy ``` ## Expected Behavior The migration job completes successfully. When `dependencyProxy.enabled: false`, the bucket should either be excluded from validation, or the chart should still pass the bucket value to the Rails config so the validation passes. ## Actual Behavior Rails initializer raises `missing_bucket_for` for `dependency_proxy` even though a bucket name is provided in the Helm values. The error occurs at app boot, before any migration runs. ## Root Cause (Suspected) When `dependencyProxy.enabled: false`, the chart appears to omit the `dependency_proxy` bucket from the generated Rails object storage configuration. A new or stricter validation in GitLab 17.11.x (`object_store_settings.rb:234`) now checks the bucket for all storage types — including those with object storage disabled — when consolidated object storage is active. ## Workaround Set `dependencyProxy.enabled: true` with a valid bucket to satisfy the validation, even if the Dependency Proxy feature itself is not being used: ```yaml global: appConfig: dependencyProxy: enabled: true bucket: gitlab-dependency-proxy ``` ## Environment - Chart version: `9.11.0` - Helm: `3.x` - Consolidated object storage: enabled