GitLab Cloud Native Chart 8.0

Along with the 17.0 release of GitLab, we have bumped the chart version to 8.0.

Summary of major changes

See GitLab 17 changes for all upgrade relevant changes.

Upgrade path from 7.x

To upgrade to the 8.0 version of the chart, you first need to upgrade to the latest 7.11.x release of the chart. Check the version mapping details for the latest patch.

Upgrade to 8.8.0

If you disabled the shared-secrets job, you’ll need to manually create three new secrets. If you have it enabled (default behavior), then there’s nothing to do, as the new secrets will be auto-generated.

  • active_record_encryption_primary_key
  • active_record_encryption_deterministic_key
  • active_record_encryption_key_derivation_salt

The secrets format can be seen in the GitLab Rails secrets section.

Here are the steps to populate these 3 secrets:

  1. Back up the secrets.

  2. Generate 3 different 32-chars random strings –one for each of the new secrets– with LC_ALL=C < /dev/urandom tr -dc 'a-zA-Z0-9' | head -c 32

  3. Add the secrets at the end of gitlab-secrets.yaml:

    YAML Copy to clipboard
    active_record_encryption_primary_key:
      - "<first 32-chars random string>"
    active_record_encryption_deterministic_key:
      - "<second 32-chars random string>"
    active_record_encryption_key_derivation_salt: "<third 32-chars random string>"
  4. Create a new secret resource (replace <name> with the name of the release):

    Shell Copy to clipboard
    kubectl create secret generic <name>-rails-secret-v2 --from-file=gitlab-secrets.yaml
  5. Update the global.railsSecrets.secret in your values.yaml file to point to the new <name>-rails-secret-v2 secret resource.

  6. Upgrade the GitLab Chart release with this new value, but making sure other old values still apply (for example, don’t use the --reuse-values flag).

  7. Confirm that GitLab is working as expected. If it is, it should be safe to delete the old <name>-rails-secret secret resource.

Upgrade to 8.6.0

The app label of the Job that performs the database migrations for the registry metadata database has been changed from registry to registry-migrations to address issues with the selectors of the container registry Deployment and PodDisruptionBudget.

If you don’t have the registry metadata database enabled, or don’t use it in any external tools such as monitoring or logging solutions, you don’t need to do anything. If you do use this label, please update it accordingly.

Upgrade to 8.6.x, 8.5.1, 8.4.3, 8.3.6

This change affects you only if you’re using the GitLab NGINX chart, and you have set your own NGINX RBAC rules.

If you’re using your own external NGINX chart, or you’re using the GitLab NGINX chart without any NGINX RBAC rules changes, you can skip this section.

In Helm chart versions 8.6.0, 8.5.1, 8.4.3, 8.3.6, the Ingress NGINX Controller image was bumped to v1.11.2, but the Ingress NGINX Controller chart version is still on 4.0.6. The old v1.3.1 controller image is now deprecated and scheduled for removal in GitLab chart 9.0.

When upgrading to the mentioned chart versions, by default the v1.11.2 will be set. The chart will automatically fallback to v1.3.1 if the you’re setting nginx-ingress.rbac.create or to false (same applies to Geo nginx-ingress-geo.rbac.create). This is because v1.11.2 requires new RBAC rules, which we added to our NGINX chart.

If you’re managing your own NGINX RBAC rules, and want to use the new v1.11.2 before it’s enforced in GitLab 18.0 (Helm chart 9.0):

  1. Apply the new RBAC rules to your cluster (example):

    YAML Copy to clipboard
    - apiGroups:
       - discovery.k8s.io
     resources:
       - endpointslices
     verbs:
       - list
       - watch
       - get
  2. Enable the controller image v1.11.2 with:

    YAML Copy to clipboard
    nginx-ingress:
      rbac:
        create: false
      controller:
        image:
          disableFallback: true

Runner workflow changes

The legacy runner registration workflow is now disabled by default. You must migrate to the new registration workflow or re-enable the legacy workflow.

Refer to the runner sub-chart documentation for migration instructions.