Support Engineers 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.
You can create (ephemeral) testing environments. We recommend using the support-resources project for doing so.
support-resources automation (preferred)Use the 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. This is the preferred way to create GitLab testing instances. If you don't have access to this project, please create an access request and assign your manager for approval.
If you need additional flexibility for creating test environments. The GitLab Sandbox Cloud allows for creating a personally-owned GCP project. You can do so using the GCP console, or gcloud command line tool. If you need to replicate any of the Reference Architectures, it's recommended that you use the GitLab Environment Toolkit.
Note: Please remember to shut down resources that you are no longer using. The personally-owned GCP projects aren't yet making use of the frugal resources tool for automating the shut down of resources created in your own project.
You can use the support-resources project to manually create resources in a GCP testing environment alongside the resources created by our automation tools. As with the GitLab Sandbox Cloud for GCP - you can manage these manually created resources using the GCP console, or gcloud command line tool.
Warning: You may also have access to the gitlab-internal and gitlab-support GCP projects. It's strongly recommended that you make use of the support-resources project or the GitLab Sandbox Cloud, instead of creating new resources in these projects.
We also have a support-openshift project created for the purpose of creating OpenShift clusters for testing the GitLab Operator and GitLab Runner Operator. Reach out to your Support Team colleagues in the #support-testing Slack Channel for more details on using this project for shared OpenShift testing.
Note: Please remember to shut down any manually created that you are no longer using.
Please use the support-resources GCP project or your GitLab Sandbox Cloud GCP project to create a GCP Kubernetes (GKE) cluster. If you are using the support-resources GCP project you can create a GKE cluster manually from the console or you can use the Support-resources automation project to streamline your GKE cluster creation and there's even an option to create a GKE cluster that already has GitLab installed through helm chart.
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.
Please use Sandbox Cloud to create credentials for AWS.
For Group SAML/SCIM (GitLab.com) testing, shared account credentials can be located within the 1password entry Azure Active Directory Sandbox (SAML Testing). This level of access should be sufficient for the majority of test cases.
If you need access to the shared infrastructure team's Azure account for testing AKS and similar features, please create an access request and tag your manager.
For features not available in either instance, please create your own trial for Azure.
If you need an Okta sandbox environment to test SAML and SCIM, please go to https://developer.okta.com/signup/ and enter your credentials for a free developer instance where you can perform all your tests. This is a full featured environment so you should be able to add and remove applications, and perform all tests as if you were in a regular production instance.
For testing LDAP integrations with a self-managed GitLab instance, you may consider any of these options:
If you wish to test resources using a real domain name (instead of an IP address, e.g. for testing TLS certificates), you can use a subdomain of gitlab.support. You can confgure this in GCP in the gitlab-support project here.
Warning: Digital Ocean (DO) and dev-resources is 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.
Since Docker Toolbox has been deprecated, Docker Machine has to be downloaded and installed manually. Use the following commands to install or upgrade Docker Machine sepparately:
$ curl -L https://github.com/docker/machine/releases/download/v0.16.2/docker-machine-`uname -s`-`uname -m` >/usr/local/bin/docker-machine && \
chmod +x /usr/local/bin/docker-machine
This guide involves configuring and setting up VMWare and Docker locally and assumes you're using macOS.
This guide involves configuring and setting up VirtualBox and Docker locally and assumes you're using macOS.
Oracle VM VirtualBox is a free and open-source hosted hypervisor for x86 virtualization.
Note The following list of commands can be saved as bash script for quickly spinning up new instances
Vagrant is a tool for building and managing virtual machine environments in a single workflow
Vagrant encapsulates the local VM apps VMWare and Virtual along with libvirt.
To install Vagrant, go to tutorials/vagrant/getting-started-install
Once installed, support/toolbox has two projects which you can explore for local GitLab and tools setup.
Support toolkit to help manage GitLab inventory and additional services via docker containers.
Provide a common provisioning and directory structure for various support setups including GitLab with connected GitLab Runners.
export SSH_PORT=2222
export HTTP_PORT=8888
export VERSION=11.9.9-ee.0
export ENV_NAME=gitlab-test-env
export CONTAINER_NAME=gitlab-test-11.9
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 $ENV_NAME
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 IP=$(docker-machine ip $ENV_NAME)
docker run --detach \
--env GITLAB_OMNIBUS_CONFIG="external_url 'http://$IP:$HTTP_PORT'; gitlab_rails['gitlab_shell_ssh_port'] = $SSH_PORT;" \
--hostname $IP \
-p $HTTP_PORT:$HTTP_PORT -p $SSH_PORT:22 \
--name $CONTAINER_NAME \
gitlab/gitlab-ee:$VERSION
echo $IP
# example output: 192.168.151.134
Note: The container might take a few seconds to spin up and become accessible via the browser.
docker exec -it $CONTAINER_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
