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.
#
stages:
  - 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](https://github.com/GoogleContainerTools/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.
build:
  stage: build
  rules:
    - if: $CI_MERGE_REQUEST_IID
  image:
    name: gcr.io/kaniko-project/executor:debug
    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.
  before_script:
    - mkdir -p /kaniko/.docker
    - |
      cat > /kaniko/.docker/config.json <<EOF
      {
          "auths": {
             "${CI_REGISTRY}":{
                 "auth":"$(printf '%s:%s' "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')"
             }
          }
      }
      EOF
  script:
    - >-
      /kaniko/executor
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
      --destination "${CI_REGISTRY_IMAGE}:${CI_PIPELINE_IID}"
      --destination "${CI_REGISTRY_IMAGE}:latest"
      --cache=true


# 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.
aptori-analysis:
  stage: test
  rules:
    - if: $CI_MERGE_REQUEST_IID
  image:
    # 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:
    # https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#override-the-entrypoint-of-an-image
    entrypoint: ['']
  services:
    # 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.
    - name: "${CI_REGISTRY_IMAGE}:${CI_PIPELINE_IID}"
      alias: "app"
  script:
    # 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"
        --label="job=${CI_JOB_ID}"
        --label="commit=${CI_COMMIT_SHA}"
        --label="pipeline=${CI_PIPELINE_IID}"