• Requirements
• Parameters
  • Tool pointer variables ($KIND, $KUBECTL, $HELM, etc.)
• GCP
• KinD
• Runner deployment

GitLab autodeployment for testing

Requirements

• openssl utility
• kubectl
• task
• cluster interaction tool (one of):
  • gcloud
  • kind

Parameters

Parameters are passed via environment variables:

Tool pointer variables ($KIND, $KUBECTL, $HELM, etc.)

Main use of tool pointer variables is to point to particular tool path or path to a wrapper script (like k for kubectl, for example).

One of the alternative uses for any one of those variables is to get some debugging info:

KUBECTL="echo kubectl" provision_and_deploy.sh deploy_operator

However, this can also be achieved by using bash -x provision_and_deploy.sh.

GCP

Example with Cert-Manager (ran from the root of gitlab-operator repo):

export GITLAB_CHART_DIR=~/work/gitlab \
       GITLAB_OPERATOR_DOMAIN="mydomain.k8s-ft.win" \
       GITLAB_ACME_EMAIL="somebody@gitlab.com" \
       GITLAB_CR_DEPLOY_MODE="certmanager"

# https://docs.gitlab.com/charts/installation/cloud/gke.html
PROJECT="gcp-project-123" CLUSTER_NAME="mydomain" \
    bash ${GITLAB_CHART_DIR}/scripts/gke_bootstrap_script.sh up

# ...wait for provisioning to complete
scripts/provision_and_deploy.sh generic_deploy

Alternatively, use a CR generated by a pipeline (downloaded into ./123-my-branch.yaml, for example):

cd scripts
export GITLAB_CHART_DIR=~/work/gitlab \
       GITLAB_OPERATOR_DIR=~/work/gitlab-operator \
       GITLAB_OPERATOR_MANIFEST=./123-my-branch.yaml \
       GITLAB_OPERATOR_DOMAIN="mydomain.k8s-ft.win" \
       GITLAB_ACME_EMAIL="somebody@gitlab.com" \
       GITLAB_CR_DEPLOY_MODE="certmanager"

PROJECT="gcp-project-123" CLUSTER_NAME="mydomain" \
    bash ${GITLAB_CHART_DIR}/scripts/gke_bootstrap_script.sh up

# ...wait for provisioning to complete
./provision_and_deploy.sh generic_deploy

The command above has been run from the within scripts/ directory (note the use of GITLAB_OPERATOR_DIR).

One can deploy with self-signed certs, in which case KIND_LOCAL_IP should be provided (use “cluster IP”) and not GITLAB_OPERATOR_DOMAIN.

KinD

By default deployment is done with Self-Signed cert:

export KIND_CLUSTER_NAME=gitlab \
       KIND_LOCAL_IP=192.168.3.194 \
       GITLAB_CHART_DIR=~/work/gitlab

scripts/provision_and_deploy.sh kind_deploy

Alternatively, use a CR generated by a pipeline in build manifest job (downloaded into ./123-my-branch.yaml, for example):

export KIND_CLUSTER_NAME=gitlab \
       KIND_LOCAL_IP=192.168.3.194 \
       GITLAB_CHART_DIR=~/work/gitlab \
       GITLAB_OPERATOR_MANIFEST=./123-my-branch.yaml \
       GITLAB_OPERATOR_DIR=~/work/gitlab-operator

scripts/provision_and_deploy.sh kind_deploy

That’s it! You should now be able to navigate to https://gitlab.(your IP).nip.io and log in with the root password.

NOTE: Use of cert-manager for generating certificates for Ingresses in KinD is not possible unless your KinD instance is publicly accessible.

Runner deployment

Once base deployment has been performed do the runner deployment (retaining same exported variables):

scripts/provision_and_deploy.sh runner_deploy

Alternatively, do everything in one go (we’ll use kind deploy for example):

scripts/provision_and_deploy.sh kind_deploy runner_deploy