Support Engineer's need testing environments to learn how to support GitLab and also to replicate customer issues.
This page explains the main choices available to you. Some guidelines:
Have fun!
You can always create a group. As usual, public projects get Gold features, but if you need to test paid group features or in a private project, Support has groups for each paid tier.
Typically, Support team members are added as Owner in these groups, while other team members are added as Maintainer or Owner with an expiry date.
If you require access, please ask an existing owner.
If you require a group of your own to have a paid tier, please submit an access request.
For a test license you can log into LicenseDot with your GitLab login. You can use one of the shared licenses or if you need special add-ons, such as geo, you can generate a new one.
Please keep in mind you can't generate licenses for customers only for testing purposes. To generate a new license, log in to LicenseDot and click on the 'New License' green button on the right side of the screen. Click on "You can also manually create a license without a Zuora subscription" at the bottom of the screen and fill out all non-optional fields.
As a member of support, you have access to a variety of ephemeral testing environments. You can build and tear down whatever resources you need to reproduce customer environments, try new features or learn about deploying a new topology.
The resources that are created in these environments are:
There's 2 stages to approach creating your Ephemeral Testing instances. The first stage is to provision the infrastructure (in either GCP, DO, AWS, Azure, Okta) followed by the second stage where our products are deployed to the servers.
Note: Please be aware that we don't have access to the DO console and we are moving away from DO and focusing on using GCP as our cloud provider. Also we are transitioning from using the dev-resources project in favor of support-resources.
Login to GCP console using your GitLab Google account credentials.
You can use support-resources to automatically spin up resources. They will appear in the support-resources GCP project. All Support Engineers should have access to this project.
If you need to manually create resources in a GCP Testing environment, please use the gitlab-support project.
You should have access to this as a baseline entitlement. If you do not, please create an access request and tag your manager.
Note: you may also have access to the gitlab-internal GCP project. You should not create resources in this project.
You should also have access to the support-resources project and be able to use support-resources as a means of spinning up complex resources in a convenient and programmatic way. With this project you are able to directly GitLab and Runner instances as well as regular Basic server instances (for which you can follow the steps in Creating GitLab Test Instance to continue to install GitLab).
Select Kubernetes Engine from the dashboard, and then Create Cluster. Enter a name, select a zone, and choose the default static master version unless you have a specific reason to use an alternative version. It's important to use a server version that will match your kubectl client version.
All of the remaining options can be left as their default settings unless you have a need to add customization to your cluster. Of note, the Maximum Pods per Node option directly correlates with the CIDR assignment of your node(s).
Connecting to, and configuring, your cluster can be done locally using gcloud and kubectl. Or you can use the Google Cloud Shell. Clicking Connect in GCP will provide the command to run locally for you to copy and paste, or let you open Cloud Shell immediately. Using docker images is also an option for a quick deployment of all tools locally.
AWS credentials and instructions are stored in the Support Vault.
If you need access to Azure for testing, please create an access request and tag your manager.
Specifically for Group SAML/SCIM (GitLab.com) testing, shared account credentials are in 1password Azure Active Directory Sandbox (SAML Testing).
For SAML/SCIM testing, please open an access request for GitLab's Okta Preview instance with admin role and ability to add Applications.
Note: DO and dev-resources are being deprecated in favor of support-resources
For a Digital Ocean droplets follow this guide. Once you've created your resource you can follow the section named Creating GitLab test instance (though do keep in mind that we are moving away from this project).
Install Docker Desktop for Mac or the Linux Engine.
This guide involves configuring and setting up VMWare and Docker locally and assumes you're using macOS.
This command will create a new VMware fusion virtual machine called gitlab-test-env that will act as a docker host.
-1)4GBgitlab-test-envvmwarefusiondocker-machine create \
--vmwarefusion-cpu-count -1 \
--vmwarefusion-memory-size 4096 \
--vmwarefusion-disk-size 30000 \
--driver vmwarefusion gitlab-test-env
This guide involves configuring and setting up VirtualBox and Docker locally and assumes you're using macOS.
This command will create a new VirtualBox virtual machine called gitlab-test-env that will act as a docker host.
-1)4GBgitlab-test-envvirtualboxdocker-machine create \
--virtualbox-cpu-count -1 \
--virtualbox-memory 4096 \
--virtualbox-disk-size 30000 \
--driver virtualbox gitlab-test-env
In this example we'll create a GitLab EE 11.9.9 instance.
First connect the docker client to the docker host you created previously.
eval "$(docker-machine env gitlab-test-env)"
You can add this to your ~/.bash_profile file to ensure the docker client uses the gitlab-test-env docker host. You can use echo to do so:
echo 'eval "$(docker-machine env gitlab-test-env)"' >> ~/.bash_profile
Optionally replace the ee in the URL with ce
wget -q https://registry.hub.docker.com/v1/repositories/gitlab/gitlab-ee/tags -O - | sed -e 's/[][]//g' -e 's/"//g' -e 's/ //g' | tr '}' '\n' | awk -F: '{print $3}'
88882222
gitlab_shell_ssh_port using --env GITLAB_OMNIBUS_CONFIG gitlab-test-11.911.9.9-ee.0export SSH_PORT=2222
export HTTP_PORT=8888
export VERSION=11.9.9-ee.0
export NAME=gitlab-test-11.9
docker run --detach \
--env GITLAB_OMNIBUS_CONFIG="external_url 'http://$(docker-machine ip gitlab-test-env):$HTTP_PORT'; gitlab_rails['gitlab_shell_ssh_port'] = $SSH_PORT;" \
--hostname $(docker-machine ip gitlab-test-env) \
-p $HTTP_PORT:$HTTP_PORT -p $SSH_PORT:22 \
--name $NAME \
gitlab/gitlab-ee:$VERSION
docker-machine ip gitlab-test-env
# example output: 192.168.151.134
docker exec -it $NAME /bin/bash
# example commands
root@192:/# vi /etc/gitlab/gitlab.rb
root@192:/# gitlab-ctl reconfigure
For example, to set the gitlab_shell_ssh port on a container named gitlab-ee to port 2222
docker exec -it gitlab-ee \
sed -i "s/.*gitlab_shell_ssh_port.*/gitlab_rails['gitlab_shell_ssh_port'] = 2222/g" /etc/gitlab/gitlab.rb
docker exec -it gitlab-ee gitlab-ctl reconfigure
