Provider-specific testing

CI deploys Review apps to k3d clusters only. k3d covers most chart behavior, but it does not exercise the integrations of a cloud provider. When your change depends on provider-specific behavior, test it manually on that provider before you merge.

When to test on a cloud provider

Test on a cloud provider when your change affects:

  • LoadBalancer Services, their annotations, or static IP handling, like global.hosts.externalIP.
  • Integration with provider-managed load balancers or Gateway API and Ingress controllers.
  • Persistent storage, like storage classes, volume expansion, or access modes.
  • Cloud identities for object storage or other services, like GKE Workload Identity Federation, EKS IAM roles for service accounts, or Microsoft Entra Workload ID.
  • Connections to provider object storage, like Google Cloud Storage, Amazon S3, or Azure Blob Storage.
  • Scheduling on provider-managed nodes, like node pools, taints, or architectures.
  • OpenShift-specific resources, like Security Context Constraints or Routes.

For everything else, a local cluster is usually enough.

Get a cloud account

GitLab team members can create personal AWS accounts and Google Cloud projects in the Sandbox Cloud.

Clean up your clusters when you are done. Cloud resources are billed while they run.

Create a cluster

GKE

Follow Developing with a GKE cluster.

EKS

Create the cluster with eksctl:

shell
eksctl create cluster --name <cluster-name> --region us-east-2 \
  --version <version> --nodes 2 --node-type m5.xlarge

Install the Amazon EBS CSI driver before you deploy GitLab, otherwise persistent volume claims stay pending. For more information, see Persistent Volume Management.

To delete the cluster:

shell
eksctl delete cluster --name <cluster-name> --region us-east-2 --wait

For more information, see Preparing EKS resources.

AKS

Create a resource group and the cluster with the Azure CLI:

shell
az group create --name <resource-group> --location eastus
az aks create --resource-group <resource-group> --name <cluster-name> \
  --node-count 2 --node-vm-size Standard_D4s_v3 --generate-ssh-keys
az aks get-credentials --resource-group <resource-group> --name <cluster-name>

To delete the cluster and all resources in the resource group:

shell
az group delete --name <resource-group> --yes --no-wait

For more information, see Preparing AKS resources.

OpenShift

GitLab supports OpenShift through the GitLab Operator. Test OpenShift-specific changes with the Operator. For more information, see the Operator developer documentation.

Deploy GitLab

After you create the cluster, set up the external dependencies and deploy your development branch.

Document your testing

In your merge request, add a comment that describes how you tested the change:

  • The provider and Kubernetes version.
  • The values you deployed with.
  • What you verified, and the result.