Add detached pipeline and deployment workflow templates

Adds a detached pipeline workflow template which runs the CI flow for both merge requests and branches without merge requests. An additional deployment template is added to implement the default webapp deployment flow.

The detached pipeline template in this MR is a copy of gitlab-ci/auto-devops-for-detached-pipelines.yml in MR uis/devops/uga/smi!221, so see that MR for a test pipeline based on the detached pipeline workflow template.

The deployment template in this MR is basically a copy of the SMI deploy CI config file with the webapp URLs converted to variables, and some optimisation of the rules.

Closes #5 (closed)

Closes #6 (closed)

auto-devops/deploy.yml

+# Overrides Auto-DevOps template from GitLab to implement the deployment
+# workflow.
+#
+# This template is intended to be generic and to be "include"-d from CI
+# configurations. It pulls in the UIS detached pipeline workflow template
+# (which also pulls in the Auto-DevOps template). To use this template,
+# make sure it's the first template to be "include"-d.
+#
+# include:
+#   - project: 'uis/devops/continuous-delivery/ci-templates'
+#     file: '/auto-devops/deploy.yml'
+#
+# Speed up deployment jobs by disabling Auto-DevOps jobs that are not needed
+# in the deployment project, and all non-deployment jobs when actually
+# deploying (that is, when DEPLOY_ENABLED is defined to indicate the deployment
+# target).
+#
+# The webapp URL for each deployment target must be specified by defining the
+# variables WEBAPP_URL_DEVELOPMENT, WEBAPP_URL_STAGING and
+# WEBAPP_URL_PRODUCTION.
+#
+# This template will need updating as Auto-DevOps updates.
+
+include:
+  - project: 'uis/devops/continuous-delivery/ci-templates'
+    file: '/auto-devops/detached-pipelines.yml'
+
+variables:
+  # Disable Auto-DevOps jobs that we don't need in the deployment project
+  DEPENDENCY_SCANNING_DISABLED: "any-value"
+  DAST_DISABLED: "any-value"
+  SAST_DISABLED: "any-value"
+
+.default-no-deploy: &default-no-deploy
+  rules:
+    - if: $DEPLOY_ENABLED
+      when: never
+    - if: $CI_MERGE_REQUEST_IID || $CI_COMMIT_TAG || $CI_COMMIT_BRANCH
+
+# Build stage
+build:
+  <<: *default-no-deploy
+
+# Tests and checks
+code_quality:
+  <<: *default-no-deploy
+container_scanning:
+  <<: *default-no-deploy
+license_scanning:
+  <<: *default-no-deploy
+# TODO: Add `secret_detection` when upgrading to GitLab 13.1
+#secret_detection:
+#  <<: *default-no-deploy
+
+
+# The "test" job will run the following test that Terraform's "fmt" utility does
+# not request any changes.
+test:
+  image: docker:stable-git
+
+  services:
+    - docker:stable-dind
+
+  before_script:
+    # Pull image from registry. Use TOX_IMAGE if defined, otherwise default to
+    # the image which was built in the build step.
+    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
+    - |-
+      if [[ -z "$CI_COMMIT_TAG" ]]; then
+        export CI_APPLICATION_REPOSITORY=$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG
+        export CI_APPLICATION_TAG=$CI_COMMIT_SHA
+      else
+        export CI_APPLICATION_REPOSITORY=$CI_REGISTRY_IMAGE
+        export CI_APPLICATION_TAG=$CI_COMMIT_TAG
+      fi
+
+    # Pull built image from registry. The image tag here matches the one built
+    # by the Auto DevOps pipeline.
+    # See: https://gitlab.com/gitlab-org/cluster-integration/auto-build-image/blob/master/src/build.sh#L31
+    - IMAGE_TAG="${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG}"
+    - docker pull "${IMAGE_TAG}"
+
+  script:
+    # Run terraform's format checker.
+    - docker run --rm "${IMAGE_TAG}" terraform fmt -recursive -check .
+
+  # Job will start early by default, so make it depend on the build job completing
+  needs: ["build"]
+
+  <<: *default-no-deploy
+
+
+# Triggered by manually running the pipeline with DEPLOY_ENABLED="development"
+# and WEBAPP_DOCKER_IMAGE set to the image to deploy
+deploy_webapp_development:
+  extends: .cloud-run-deploy
+  stage: staging
+  environment:
+    name: development/webapp
+    url: $WEBAPP_URL_DEVELOPMENT
+  variables:
+    DEPLOY_ENV: "DEVELOPMENT"
+  only:
+    variables:
+      - $DEPLOY_ENABLED == "development"
+
+
+# Intended to be triggered remotely by webapp CI setting WEBAPP_DOCKER_IMAGE to
+# the latest master image and DEPLOY_ENABLED="staging"
+deploy_webapp_staging:
+  extends: .cloud-run-deploy
+  stage: staging
+  environment:
+    name: staging/webapp
+    url: $WEBAPP_URL_STAGING
+  variables:
+    DEPLOY_ENV: "STAGING"
+  only:
+    variables:
+      - $DEPLOY_ENABLED == "staging"
+
+
+# Triggered manually within the same pipeline which deployed the staging
+# instance, so that WEBAPP_DOCKER_IMAGE will still be defined
+deploy_webapp_production:
+  extends: .cloud-run-deploy
+  stage: production
+  when: manual
+  environment:
+    name: production/webapp
+    url: $WEBAPP_URL_PRODUCTION
+  variables:
+    DEPLOY_ENV: "PRODUCTION"
+  only:
+    variables:
+      - $DEPLOY_ENABLED == "staging"
+
+
+# Template for deploying WEBAPP_DOCKER_IMAGE to environment given by DEPLOY_ENV
+.cloud-run-deploy:
+  image: uisautomation/gcloud-docker:latest
+  services:
+    - docker:dind
+  before_script:
+    # Use indirect variable expansion to get variables set based on CI variables
+    # set by terraform configuration for appropriate environment
+    # (extra evals seem to be needed to make variable expansion work)
+    - eval "export GOOGLE_PROJECT=\$WEBAPP_PROJECT_${DEPLOY_ENV}"
+    - export GOOGLE_CONTAINER_REGISTRY_BASE_URL="eu.gcr.io/${GOOGLE_PROJECT}"
+    - eval "export RUN_SERVICE_NAME=\$WEBAPP_RUN_SERVICE_NAME_${DEPLOY_ENV}"
+    - eval "export RUN_SERVICE_REGION=\$WEBAPP_RUN_SERVICE_REGION_${DEPLOY_ENV}"
+    - eval "export DEPLOY_CREDENTIALS=\$WEBAPP_DEPLOY_CREDENTIALS_${DEPLOY_ENV}"
+  script:
+    # Create temporary file holding credentials
+    - export GOOGLE_APPLICATION_CREDENTIALS=$(mktemp -t credentials.XXXXXX)
+    - echo "${DEPLOY_CREDENTIALS}" >"${GOOGLE_APPLICATION_CREDENTIALS}"
+
+    # Add credentials for GitLab and Google container registries.
+    - echo "Logging into ${CI_REGISTRY} as ${CI_REGISTRY_USER}."
+    - docker login -u "${CI_REGISTRY_USER}" -p "${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}"
+    - echo "Logging into ${GOOGLE_CONTAINER_REGISTRY_BASE_URL} using Google credentials."
+    - |-
+      docker login -u _json_key -p "${DEPLOY_CREDENTIALS}" \
+        "https://${GOOGLE_CONTAINER_REGISTRY_BASE_URL}"
+
+    # Determine the name of the Google container to push.
+    - GOOGLE_IMAGE="${GOOGLE_CONTAINER_REGISTRY_BASE_URL}/${IMAGE_NAME}:gitlab-ci-job-${CI_JOB_ID}"
+
+    # Pull the GitLab container, tag it with the Google container name and push.
+    - |-
+      echo "Pulling from: ${RUN_SOURCE_IMAGE}"
+      echo "Pushing to: ${GOOGLE_IMAGE}"
+      docker pull "${RUN_SOURCE_IMAGE}"
+      docker tag "${RUN_SOURCE_IMAGE}" "${GOOGLE_IMAGE}"
+      docker push "${GOOGLE_IMAGE}"
+
+    # Activate service account credentials
+    - gcloud auth activate-service-account --key-file="${GOOGLE_APPLICATION_CREDENTIALS}"
+
+    - |-
+      gcloud beta run deploy "${RUN_SERVICE_NAME}" \
+        --project="${GOOGLE_PROJECT}" \
+        --image="${GOOGLE_IMAGE}" \
+        --platform managed \
+        --region "${RUN_SERVICE_REGION}"
+
+  except:
+    variables:
+      - "$WEBAPP_DOCKER_IMAGE == null"
+      - "$WEBAPP_DOCKER_IMAGE == ''"
+
+  variables:
+    # Informative name for image. This is used to name the image which we push
+    # to GCP. It is *not* the name of the image we pull from the GitLab
+    # container registry. The fully-qualified container name to *pull* should be
+    # set via the WEBAPP_DOCKER_IMAGE variable.
+    IMAGE_NAME: webapp
+
+    # Variables set by upstream deploy job
+    RUN_SOURCE_IMAGE: "$WEBAPP_DOCKER_IMAGE"

[Dr Rich Wareham]

How do we deal with projects with multiple webapps? E.g. https://gitlab.developers.cam.ac.uk/uis/devops/uga/deploy/-/merge_requests/19/diffs

[Dave Hart]

As long as all the deployment jobs extend .cloud-run-deploy then adding extra jobs for multiple webapps should require minimal configuration. As has been done in uis/devops/uga/deploy!19, SERVICE_PREFIX should be added as a variable to .cloud-run-deploy that permits it to be configured for multiple webapps.

[Dr Abraham Martin]

While GitLab CI documentation confirms that there is no dependency scanner for Terraform, the jobs will be skipped, so I think is safe not to include this line. Trying to be future proof and not modify autodevops when not necessary.

[Dr Abraham Martin]

I think DAST should be executed to dev and staging deployments.

[Dr Abraham Martin]

Some SAST needs to be enabled for the deployment repos, reading GitLab documentation we can see that we should be executing at least, Gitleaks, TruffleHog, Kubesec. As with others, I believe that GitLab SAST Template should be sufficiently clever to skip those that do not apply to the repo, and thus, this line shouldn't be necessary.

[Dr Abraham Martin]

I think having all these exceptions is showing that probably we are not doing it properly to make it work with AutoDevOps. I believe this is because we are executing CD jobs in the Infrastructure as code (IAC) repository. IAC still requires Gitlab CI pipelines as our infrastructure is code, so it needs testing, SAST, etc.

If we look at this CI template there is nothing in there is nothing in here that uses any code of the IAC repo. When deploying, it does not even uses the build step, or any terraform code.

The only thing that we use from the repo are the secrets. I wonder then if we are architecting our repos wrong and we need:

• WebApp repo. Webapp code. Normal AutoDevOps but with review apps. Maybe review apps deployment should used the CD repo defined below?
• Infra as code repo. Terraform code for the infrastructure. Normal AutoDevOps for checking dependencies, secrets, test, etc. Deployment happens only once (or rarely when the infra definition changes). No need for auto-deployment of infra.
• CD repo. Will only contain gitlab-ci.yml file as code. That file will only import this template. Deployment secrets will only be stored as CI env vars in this repo. Will have a button to deploy to production, after a a staging deployment has happened DAST and E2E tests have been executed against staging (probably calling the webapp repo which will contain the e2e test code).