»Integrating Waypoint with GitLab CI/CD
Using Waypoint to deploy an application from within GitLab CI/CD is similar to how you might deploy an application from your own workspace.
The example demonstrates the main steps:
- Set-up the dependencies Waypoint might use. This could be a Kubernetes context for a more advanced application, or in the below example, a Docker daemon to run applications on.
- Install Waypoint from the official source. If you are using a Docker custom image executor with your other deploy dependencies, you could utilize the public Docker image in a multi-stage build.
waypoint init. This depends on the environment variables listed below and documented in the Automating Execution overview.
- Run the build, deploy, and release. In this case, instead of using
waypoint up, it breaks out each stage as a separate command to be easier to read and filter through in the GitLab UI.
This example assumes the use of a single default workspace.
You can also use defined GitLab environments:
run: waypoint build -workspace $CI_ENVIRONMENT_NAME
If this was in a job triggered by a Git commit or merge request and may be an ephemeral development environment, you may want to interpolate the relevant Git ref for the workspace parameter, as demonstrated below:
run: waypoint build -workspace $CI_COMMIT_BRANCH
See the GitLab CI/CD predefined environment variables page for a full list of variables that could be utilized in this way.
waypoint: # GitLab created images, which basically rewraps HashiCorp's officially released binaries and may not match HashiCorp's checksums, See https://gitlab.com/gitlab-org/waypoint-images for more details about what goes into the images. image: registry.gitlab.com/gitlab-org/waypoint-images:latest stage: build services: - docker:dind variables: WAYPOINT_SERVER_ADDR: '' WAYPOINT_SERVER_TOKEN: '' WAYPOINT_SERVER_TLS: '1' WAYPOINT_SERVER_TLS_SKIP_VERIFY: '1' script: - waypoint init - waypoint build - waypoint deploy - waypoint release