Skip to content

Running Sift in a GitLab CI pipeline

To run Sift in a GitLab CI pipeline, follow these steps:

  1. Create a CI/CD Variable to store an Aptori Platform key as a secret in your project.
  2. Define a CI job in your .gitlab-ci.yml file. Examples are provided below.

Create a CI/CD Variable for Aptori Platform Key

In your GitLab project, navigate to Settings > CI/CD > Variables. Add variable SIFT_PLATFORM_KEY with the value of an Platform key created in the Aptori UI. Mark the variable as protected and masked.

Define CI job to run Sift

Edit your .gitlab-ci.yml file to define a job that runs Sift. The details of the job will depend on how you deploy the target application. Two examples are given below for an application that runs as a single container and an application that has multiple services.

Example: Single container application

The following is an example .gitlab-ci.yml file for an application that can be deployed as a single container. Stage build has job build that builds the application container and publishes container ${CI_REGISTRY_IMAGE}:${CI_PIPELINE_IID} to the GitLab project's container registry.

Stage test has job aptori-analysis that tests the application. The application is started by defining a service with alias name app. When the job finishes, the server container running the target application will be destroyed.

# This example GitLab CI/CD definition uses Aptori Sift to autonomously
# test an application comprised of a single container.
  - build
  - test

# The build job builds and publishes the application container image
# to the GitLab project's container registry.  The container tag
# $CI_PIPELINE_IID is a unique ID for the pipeline.
# [Kaniko]( is used
# to build and publish a container image to the project's GitLab
# Registry.  This job assumes there is a Dockerfile in the root of
# the project repository (see flag `--dockerfile` to specify a
# different location for the file).
# This job only runs on merge request commits.
  stage: build
    entrypoint: [""]
  # In before_script, construct a configuration file for kaniko that
  # contains the credentials required to publish to the GitLab
  # container registry (CI_REGISTRY) of the project.
    - mkdir -p /kaniko/.docker
    - |
      cat > /kaniko/.docker/config.json <<EOF
          "auths": {
                 "auth":"$(printf '%s:%s' "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')"
    - >-
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
      --destination "${CI_REGISTRY_IMAGE}:${CI_PIPELINE_IID}"
      --destination "${CI_REGISTRY_IMAGE}:latest"

# The aptori-analysis job uses Sift to run an autonomous test of the
# application's API.
# This job requires CI/CD variable SIFT_PLATFORM_KEY to be defined
# in GitLab project settings.  This variable must contain an Aptori
# Platform key.
# This job only runs on merge request commits, in order to detect
# issues before merging into the default branch.
  stage: test
    # Sift image is pulled from Docker Hub.
    name: aptori/sift
    # entrypoint is intentionally blank so that script can be passed
    # to the container and processed by a shell.  Refer to GitLab
    # documentation:
    entrypoint: ['']
    # Launch the application as a service.  GitLab will tear it down
    # after the job completes.  The container image was built by the
    # build job of this pipeline.
      alias: "app"
    # Sift uses a configuration stored in the Platform (specify a valid
    # configuration ID).  The target URL of the application is overridden using
    # flag `--target-url`.  The URL uses the service alias as the hostname.
    - sift run --config-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
        --target-url "http://app:5000"