GitLab CI
When using Loft with GitLab you can use the
official loft-ci
image as either a base image or
directly. If additional tooling is needed for your CI/CD process, a custom image can be created.
Spaces Too!
Check out the Spaces Integration section for examples of creating Spaces in a GitLab CI Pipeline.
Virtual Clusters for Merge Requests
This example shows how to create and delete a Virtual Cluster for running end-to-end tests for
the default branch and merge requests. It assumes you have configured CI/CD variables LOFT_URL
and LOFT_ACCESS_KEY
.
image: loftsh/loft-ci
stages:
- test
e2e:
rules:
- if: $CI_MERGE_REQUEST_IID
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
stage: test
before_script:
- loft login $LOFT_URL --access-key $LOFT_ACCESS_KEY
- loft create vcluster "${CI_PROJECT_NAME}-${CI_COMMIT_SHORT_SHA}-${CI_PIPELINE_ID}"
- apk add go make
script:
- kubectl apply -Rf ./kubernetes
- kubectl rollout status deployments/my-app
- make e2e
after_script:
- loft delete vcluster "${CI_PROJECT_NAME}-${CI_COMMIT_SHORT_SHA}-${CI_PIPELINE_ID}" --delete-space
Explanation:
- The
loftsh/loft-ci
image is used for all pipeline jobs and provides theloft
CLI, thedevspace
CLI, andkubectl
. - The
before_script
first logs in to loft using the$LOFT_URL
and$LOFT_ACCESS_KEY
variables that you defined in GitLab. See the GitLab docs for more information - The
before_script
then creates a virtual cluster using predefined GitLab variables to create a unique name. - Next
before_script
installs some additional tooling needed to run the end-to-end tests. For more complex scenarios creating a custom image is recommended. - Then the
script
section useskubectl
to deploy the application to the space and waits for themy-app
deployment to become ready.make
is then used to run an end-to-end test suite. - Finally
after_script
deletes the virtual cluster, and passes--delete-space
to ensure the corresponding space for the cluster is deleted. By usingafter_script
we can ensure the space is deleted even if the tests fail.