Domain and CI variables

Setting	Where	What for
HOST	CI variable	The domain the site answers on, e.g. docs.example.com. Drives the ingress and the certificate. A comma-separated list serves several domains; the first is canonical and previews are built on it
K8S_CLUSTER	CI variable	The cluster the site deploys to. Leave unset for the shared cluster
BASIC_AUTH_HTPASSWD	CI variable, optional	The password, see Password protection
gitlab-deploy-token	Deploy token, scope read_registry	Lets the pipeline pull the builder image and the cluster pull your site’s image. Without it the build stops at the very first line

Mark HOST and K8S_CLUSTER as protected so that only master and the protected preview branches reach the clusters — and then protect the branches you deploy from (dev, pr-*), otherwise the variables are empty there.

Order matters: set the variables before the first pipeline. A pipeline that runs without HOST builds and pushes the image, then starts a pod with no address and reports success. Set HOST and push again; the next deploy adds the ingress and the certificate.

DNS

A DNS-only record (no proxy) from the domain to the cluster’s ingress host; ask us for the host of your cluster. Sites under *.n2.lite.network need no record at all — the zone resolves at any depth.

How a commit becomes a deployment

1. You push to master.
2. build_container runs docker-compose build: the Dockerfile pulls the builder image, copies your content in and builds the static site; the result is packed into the nginx image and tagged with the commit’s short SHA.
3. The image is pushed to your project’s container registry.
4. deploy_master turns docker-compose.yml into Kubernetes resources — a deployment, a service, an ingress for HOST with a certificate — and applies them.
5. Kubernetes pulls the new tag and swaps the pod.

The pipeline templates themselves are quoted on How it works.