Draft: DO NOT MERGE! Validate GitLab 19 external CI dependency releases

General MR

Summary

This is a temporary Draft: DO NOT MERGE umbrella MR used to validate the integration required by GitLab package MR !473. It is not intended to become the permanent GitLab 19 umbrella update.

After the package MR is independently approved, merged, and tagged, Renovate will create the normal umbrella MR using the published GitLab package release. The durable umbrella changes validated here will be carried into that generated MR, while this temporary package commit pin will be replaced by the released chart tag.

Current validation heads:

• GitLab package: 96f0d3cb on GitLab package MR !473
• Big Bang umbrella: 14efda3fb on umbrella MR !8036

This MR validates:

• An optional addons.gitlab.dependsOn value that allows GitLab's Flux HelmRelease to wait for external dependencies. It defaults to an empty list and does not change existing deployments.
• GitLab 19 support for external PostgreSQL, Redis/Valkey, and S3-compatible object storage.
• Updated NetworkPolicy behavior for external database, Redis, and object-storage endpoints.
• GitLab 19 object-storage configuration, including consolidated Rails object storage and Registry endpoint/TLS behavior.
• Internal Big Bang test profiles using independently maintained releases instead of GitLab-owned dependency templates or subcharts.
• Standard sidecar and Istio ambient deployment profiles.

The internal validation topology is:

HelmRelease	Workload namespace	Purpose and ordering
cloudnative-pg	cloudnative-pg	Deploys the Big Bang maintained CloudNativePG operator.
postgresql	postgresql	Depends on cloudnative-pg and creates one CloudNativePG Cluster resource.
redis-wrapper / redis	redis	The Redis release waits for its Big Bang wrapper resources.
garage	garage	Provides S3-compatible object storage for the validation environment.
gitlab	gitlab	Depends on postgresql, redis, and garage. PostgreSQL's dependency on the operator provides the required transitive ordering.

The PostgreSQL operand does not require a separate custom chart. The released Big Bang wrapper chart version 0.4.15 initially renders one placeholder ConfigMap. A Flux Kustomize post-renderer replaces that complete object in memory with the single CloudNativePG Cluster/postgresql resource before Helm applies or stores the release manifest. The HelmRelease then waits for the Cluster Ready condition before GitLab can reconcile; no placeholder ConfigMap remains in the cluster.

CloudNativePG generates the PostgreSQL application Secret, and Redis generates its authentication Secret. Garage uses a fixed ephemeral test Secret because the current chart does not support an existing generated credential Secret. Kyverno generate policies copy or transform only the required connection data into the GitLab namespace. NetworkPolicies and Istio authorization rules permit only the required cross-namespace traffic.

These dependency releases are enabled only by Big Bang's internal test-value profiles. They are not enabled in consumer defaults and are not supported as development or production data services. Consumers must provide and operate GitLab-supported external PostgreSQL, Redis/Valkey, and object storage.

Relevant logs/screenshots

Static validation covers:

• Standard and ambient umbrella rendering
• OCI-value rendering
• Focused Helm unit tests
• Values-overlay BATS tests
• Package linting and template validation
• CloudNativePG resource rendering and readiness evaluation
• Dependency ordering and namespace isolation
• GitLab external-service NetworkPolicies
• Secret synchronization
• GitLab 19 backup and restore behavior

The complete staged-upgrade, dependency, application, Runner, Registry, backup/restore, Prometheus, ambient, and P1 CAC SSO evidence is available under GitLab package MR !473 — Add supporting info below.

The documented upgrade was validated from GitLab 18.11.7 using its former bundled services, through migration to external PostgreSQL 17, Redis, and Garage, and then to GitLab 19.1.3. Repository data, LFS objects, uploads, generic packages, Container Registry content, Runner pipelines, and artifacts remained available. A GitLab 19 backup was also restored successfully, and all regular and batched background migrations completed.

The skip-job-upgrade label is intentional. GitLab 19 requires a staged external-service migration that cannot be represented safely by the normal one-step automated upgrade lane.

Linked issue

Relates to GitLab package work item 412.

Supports GitLab package MR !473.

Upgrade Notices

GitLab 19 / chart 10 is a stateful major upgrade. The chart no longer bundles PostgreSQL, Redis, or MinIO, and Helm does not migrate their data.

Consumers using any formerly bundled service must migrate while still running the latest GitLab 18.11 / chart 9.11 patch. Verify GitLab against the replacement services and create a fresh backup before upgrading to chart 10. Finish all batched background migrations and any pending Advanced Search migrations first. Retain the former PVCs, Secrets, backups, and other recovery material until GitLab 19 and a new backup have been verified.

Consumers already using GitLab 19-compatible external PostgreSQL 17, Redis 7.0 or later or Valkey 7.2 or later, and GitLab-supported external object storage do not need a service-data migration solely because the bundled charts were removed. They must still complete the normal GitLab 19 pre-upgrade checks, verify every external connection and bucket, and take a fresh backup.

• Follow the upstream bundled-service migration procedure and the Big Bang-specific GitLab 19 notes.
• This release does not provide supported consumer replacements for the removed services. Configure GitLab-supported external PostgreSQL, Redis/Valkey, and external object storage before upgrading.
• If CloudNativePG is selected, install and manage the Big Bang maintained CloudNativePG operator before creating the PostgreSQL Cluster. The operator and database lifecycle remain outside the GitLab package.
• Build clean chart 10 values by removing only obsolete bundled-service keys. Preserve supported overrides, especially the existing Gitaly persistence size, because StatefulSet volume claim templates are immutable. Render and compare the chart 10 StatefulSets before reconciling.
• Existing addons.gitlab.objectStorage.endpoint and regionendpoint values must include an http:// or https:// scheme.
• Configuring external object storage enables GitLab's consolidated Rails object store by default. Explicitly set addons.gitlab.values.global.appConfig.object_store.enabled: false to retain legacy per-feature connections. Verify every bucket and the rendered Registry configuration before upgrading.
• Custom Registry configuration derives secure from the endpoint scheme, always enables v4auth, and enables pathstyle only when addons.gitlab.objectStorage.type: minio. Test Registry push, pull, and delete after upgrading.
• Direct GitLab Redis overrides must use the GitLab 19 global.redis.auth structure. Deployments using the Big Bang addons.gitlab.redis fields receive the updated structure automatically.
• This release moves GitLab application images from Iron Bank to Verified Publisher CNG images under registry1.dso.mil/gitlab/gitlab-org/build/cng/*. No separate data migration is required, but Registry1 credentials, mirrors, admission policies, and allowlists must permit the new repository path.
• Review the GitLab 19 breaking changes, GitLab deprecations and removals, chart 10 upgrade notes, and GitLab 19 upgrade changes for deployment-specific impacts.