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: 

    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): 

    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

If you haven’t modified the GitLab chart nginx-ingress.rbac.create value, or it’s set to true, you can skip this section.

In these versions, 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 schedule for removal in GitLab chart 9.0.

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 to false. This is because v1.11.2 requires new RBAC rules, which we added to our NGINX forked chart.

If you’re using managing NGINX RBAC rules by yourself, and want to use the new v1.11.2, apply the new RBAC rules to your cluster , and enable v1.11.2 with: 

nginx-ingress:
  rbac:
    create: false
  controller:
    image:
      disableFallback: true

If you’re setting nginx-ingress-geo.rbac.create: false, the same applies.

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.