.gitlab-ci.yml

# This file is the initial entrypoint for GitLab CI/CD builds. It serves primarily as a
# "driver" for other jobs: instead of executing build logic itself, it identifies which
# jobs pertain to the branch being built and dispatches those. (The exception to this is
# the Drush logic, which is encapsulated by a Node.js script in the ci/ directory.)

stages:  
  # Applications of the infrastructure Terraform module. This has to occur first because,
  # without it, Docker builds could attempt to push to empty ECR repositories.
  # First step is to build the traefik module as the traefik service is created and updated in the infrastructure module
  - infrastructure_preprod_build
  - infrastructure_preprod_west_init
  - infrastructure_preprod_west_validate
  - infrastructure_preprod_west_plan
  - infrastructure_preprod_west_apply
  - infrastructure_preprod_init
  - infrastructure_preprod_validate
  - infrastructure_preprod_plan
  - infrastructure_preprod_apply
  
  
  # Docker builds
  - build
  - copy
  - Image Scan
  
  - deploy:dev:init:en
  - deploy:dev:validate:en
  - deploy:dev:plan:en
  - deploy:dev:apply:en

  - deploy:dev:init:es
  - deploy:dev:validate:es
  - deploy:dev:plan:es
  - deploy:dev:apply:es

  - deploy:dev-west:init:en
  - deploy:dev-west:validate:en
  - deploy:dev-west:plan:en
  - deploy:dev-west:apply:en

  - deploy:dev-west:init:es
  - deploy:dev-west:validate:es
  - deploy:dev-west:plan:es
  - deploy:dev-west:apply:es
  
  - deploy:stage:init
  - deploy:stage:validate
  - deploy:stage:plan
  - deploy:stage:apply

  # Drush
  - update:es
  - update:en
  
  # Create Release
  - artifacts
  - release
  
  #Add "test" stage for Gitlab Scanners
  - test

# Our GitLab runner environment is Docker-based, so we apply this tag to every step.
default:
  tags:
    - docker

# Define this variable once here and allow it to cascade down into jobs and child
# pipelines.
variables:
  WEBCMS_IMAGE_TAG: $CI_COMMIT_REF_SLUG-$CI_COMMIT_SHA

#Including Gitlab scan templates
include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml

#region Templates

# This is the base template for all jobs in this pipeline.
.terraform:
  image:
    name: registry.gitlab.com/gitlab-org/terraform-images/releases/0.14:latest
    entrypoint: ['']

  variables:
    # Derive the root from the project directory and module name
    TF_ROOT: $CI_PROJECT_DIR/terraform/$TF_MODULE

    # Tell Terraform we are running in automation and should fail if it finds missing inputs
    # instead of attempting to read from the console.
    TF_INPUT: '0'
    TF_IN_AUTOMATION: '1'

    # Proxy input variables from our convention to variables recognizable by Terraform. We
    # can do this unconditionally because Terraform only inspects the environment when it
    # sees a declaration, sparing us from spurious warnings about values for undeclared
    # variables.
    TF_VAR_environment: ${WEBCMS_ENVIRONMENT}
    TF_VAR_site: ${WEBCMS_SITE}
    TF_VAR_lang: ${WEBCMS_LANG}
    TF_VAR_image_tag: ${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHA}
    TF_VAR_aws_region: ${AWS_REGION}

  # Use a granular cache for Terraform providers, bucketing by both module and branch.
  cache:
    key: tf-${TF_MODULE}-${CI_COMMIT_REF_SLUG}
    paths:
      - ${TF_ROOT}/.terraform

  # Every job begins execution in the module's root directory with:
  # 1. An empty http backend configuration to be filled in by the gitlab-terraform helper,
  #    and
  # 2. A copy of the GitLab-injected TERRAFORM_TFVARS file variable. (This variable is a
  #    reference to a path in a temporary directory, so we copy it in order to allow
  #    Terraform to see it automatically.)
  #
  # We do not explicitly invoke `gitlab-terraform init` because the helper script does
  # this automatically as needed.
  before_script:
    - cd $TF_ROOT
    - cp $backend_tf backend.tf
    - cp "$TERRAFORM_TFVARS" terraform.tfvars

.init:
  extends: .terraform
  stage: infrastructure_preprod_init

  script:
    - gitlab-terraform init -upgrade
    - gitlab-terraform init

.validate:
  extends: .terraform
  stage: infrastructure_preprod_validate
  needs: ["init"]

  script:
    - gitlab-terraform validate

# Perform a plan, uploading the plan files as GitLab artifacts.
.plan:
  extends: .terraform
  stage: infrastructure_preprod_plan
  needs: ["validate"]

  script:
    - gitlab-terraform plan
    - gitlab-terraform plan-json

  artifacts:
    name: plan
    paths:
      - $TF_ROOT/plan.cache
    reports:
      terraform: $TF_ROOT/plan.json

.apply:
  extends: .terraform
  stage: infrastructure_apply
  needs: [".init"]

  # Download the plan files from the previous step.
  dependencies: [plan]

  script:
    - gitlab-terraform apply

  # We use GitLab's rules to limit when we block the application of a Terraform module.
  #
  # There are three rules:
  # 1. We require approval of the infrastructure module on its tracking branches (main and
  #    live).
  # 2. We permit automatic application of the webcms module, since it only updates a
  #    limited subset of ECS resources.
  # 3. Any other attempt to apply a Terraform plan is explicitly denied. This is provided
  #    as a safety net to keep misconfigured trigger jobs from accidentally clobbering
  #    live AWS resources.
  #
  # NB. GitLab uses a "first match wins" order of rule evaluation, which is why the third
  # rule does not have an `if:` condition limiting when it applies.
  rules:
    - if: >-
        $TF_MODULE == "infrastructure" &&
        ($CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
      when: manual

    - if: >-
        $TF_MODULE == "webcms" &&
        ($CI_COMMIT_BRANCH == "integration" || $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
      when: on_success

    - when: never



# Jobs defined in this section are template jobs (the leading dot tells GitLab to
# unconditionally ignore them when assembling a pipeline graph). The templates are named
# after the stage in which they execute, and serve as central locations for the
# boilerplate that each step needs to execute. The pipelines here are not complicated in
# the sense that there are a large _variety_ of steps involved; there is instead a large
# _number_ of steps, and cutting down on repetitious information helps avoid visual noise
# when reading this file.
#
# Each template is guaranteed to include the following items:
# 1. The stage in which the job should execute
# 2. The actual job logic itself (which pipeline to trigger or which script to execute).
#
# While some templates may have additional supporting definitions/conveniences, extensions
# MUST provide the following:
# 1. Which environment ($WEBCMS_ENVIRONMENT) this job applies to.
# 2. Where applicable, the site ($WEBCMS_SITE) and language ($WEBCMS_LANG) this job
#    applies to.
# 3. Any throttling/parallelism limitations (e.g., the resource_group: keyword).
# 4. Branch limitations.
#
# Some of this information could be automatically derived in the template, but this can
# very easily cause confusion, so we instead mandate that jobs that extend a template
# repeat the logic to provide clarity on when a job is executed by GitLab, and how
# parallel it is permitted to be.

# Infrastructure jobs apply the Terraform module of the same name. They always trigger
# the Terraform pipeline with $TF_MODULE set to the same value.
.infrastructure:
  extends: .terraform
  tags:
    - docker
  variables:
    TF_MODULE: infrastructure
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev

# Build jobs perform a Kaniko build. We create a child pipeline due to the number of
# images that are built (at least Drupal, nginx, and Drush).
.build:
  stage: build

  trigger:
    include: .gitlab/docker.yml
    strategy: depend

# Deploy jobs use Terraform to create/update the ECS task definitions and services that
# make up the Drupal WebCMS.
.deploy:
  stage: deploy
  extends: .terraform
  tags:
    - docker

  variables:
    TF_MODULE: webcms
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-webcms-$WEBCMS_LANG

# Update jobs invoke Drush to perform the necessary maintenance commands (drush updb,
# drush cim) against the freshly-updated cluster. See the ci/ directory for more
# information on the update script.
.update:
  stage: update

  # Run inside a Node.js image. At the time of writing, Node.js 14 is the latest stable
  # version.
  image:
    name: node:14-alpine
    entrypoint: ['']

  # See the comments below for why the npm cache is redirected.
  script:
    - cd $CI_PROJECT_DIR/ci
    - npm ci --production --prefer-offline --cache .npm
    - node drush.js

  # Per https://docs.gitlab.com/ee/ci/caching/#cache-nodejs-dependencies, GitLab doesn't
  # support caching outside the project directory, so we have to relocate the .npm cache
  # directory inside the project root.
  cache:
    key: npm-drush
    paths:
        - ci/.npm

#endregion

# This is the template job for all Kaniko builds. Every job, regardless of what is being
# built or copied, uses this configuration:
# 1. Builds are executed in the latest Kaniko image,
# 2. Builds can opt into remote layer caching by adding $KANIKO_CACHE_ARGS to their
#    script, and
# 3. A before_script ensures that AWS ECR is added to Kaniko's credential store.
.kaniko:
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: ['']

  variables:
    KANIKO_CACHE_ARGS: --cache --cache-repo=$WEBCMS_REPO_URL/webcms-$WEBCMS_ENVIRONMENT-cache

  before_script:
    - mkdir -p /kaniko/.docker
    - echo '{"credsStore":"ecr-login"}' >/kaniko/.docker/config.json
    - echo $WEBCMS_REPO_URL/webcms-$WEBCMS_ENVIRONMENT-$WEBCMS_SITE-$WEBCMS_TARGET:$WEBCMS_IMAGE_TAG
    
#region Image builds

# We build Drupal-based images using another parallel:matrix: to cut down on the repetition
# of the fairly long invocation of the Kaniko command line.

build:drupal:
  extends: .kaniko
  stage: build
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

   # These correspond to the three production targets in services/drupal/Dockerfile. The
   # ordering here is important for builds with a limited pool of servers: by ensuring that
   # the Drupal build is executed first, it increases the chances that expensive
   # intermediate layers (such as building the ElastiCache client or building the theme)
   # already exist by the time the nginx and Drush targets need to copy that data.
  parallel:
    matrix:
      - WEBCMS_TARGET: [drupal, nginx, drush]
        WEBCMS_SITE: [dev]

   # In addition to the shared cache arguments, we provide additional settings to tune
   # Kaniko's caching behavior. This is due to the large number of files and steps in the
   # WebCMS Dockerfile:
   #
   # - We skip stages that don't apply to this build target.
   #
   # - We use the faster but less accurate redo snapshot mode, under the assumption that
   #   changes in files like composer.json or custom modules will be sufficient to disrupt
   #   the metadata cache.
   #
   # - We opt in to the (experimental) "new run" system to detect when to re-execute RUN
   #   instructions. According to the Kaniko documentation, "[i]n some cases, this may
   #   improve build performance by 75%".
  script:
    - cp $auth_json $CI_PROJECT_DIR/services/drupal/auth.json
    - /kaniko/executor
      $KANIKO_CACHE_ARGS
      --skip-unused-stages
      --snapshotMode=redo
      --use-new-run
      --context=$CI_PROJECT_DIR/services/drupal
      --build-arg GIT_COMMIT=$CI_COMMIT_SHA
      --build-arg GIT_TAG=$CI_COMMIT_TAG
      --target=$WEBCMS_TARGET
      --destination=$WEBCMS_REPO_URL/webcms-$WEBCMS_ENVIRONMENT-$WEBCMS_SITE-$WEBCMS_TARGET:$WEBCMS_IMAGE_TAG
      --destination=$WEBCMS_REPO_URL_WEST/webcms-$WEBCMS_ENVIRONMENT-$WEBCMS_SITE-$WEBCMS_TARGET:$WEBCMS_IMAGE_TAG
      --destination=$CI_REGISTRY_IMAGE/webcms-$WEBCMS_ENVIRONMENT-$WEBCMS_SITE-$WEBCMS_TARGET:$WEBCMS_IMAGE_TAG
      
  variables:
    WEBCMS_ENVIRONMENT: preproduction

 # Build the FPM metrics sidecar container.
.build:metrics:dev:
  extends: .kaniko
  stage: build
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  script:
    - /kaniko/executor
      $KANIKO_CACHE_ARGS
      --context=$CI_PROJECT_DIR/services/metrics
      --build-arg GIT_COMMIT=$CI_COMMIT_SHA
      --build-arg GIT_TAG=$CI_COMMIT_TAG
      --destination=$WEBCMS_REPO_URL/webcms-$WEBCMS_ENVIRONMENT-$WEBCMS_SITE-fpm-metrics:$WEBCMS_IMAGE_TAG
      --destination=$WEBCMS_REPO_URL_WEST/webcms-$WEBCMS_ENVIRONMENT-$WEBCMS_SITE-fpm-metrics:$WEBCMS_IMAGE_TAG
      --destination=$CI_REGISTRY_IMAGE/webcms-$WEBCMS_ENVIRONMENT-$WEBCMS_SITE-fpm-metrics:$WEBCMS_IMAGE_TAG
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    
 #endregion

 #region Docker Hub mirrors

 # As mentioned in the comments above, this stage is for mirroring Docker Hub images. Our
 # GitLab CI/CD environment is restricted - we aren't permitted access to the Docker daemon
 # and thus can't use Docker-in-Docker. Fortunately, we can slightly misuse Kaniko to
 # accomplish this task by creating an empty workspace with a single-line Dockerfile
 # referencing the image and tag we want to mirror. By performing a "build" in this
 # workspace, Kaniko will pull the image, retag it with the ECR destination, and push it.
 # This bypasses the need for the `docker pull` and `docker push` commands.

 # Jobs in this stage will almost always only execute on branches that track AWS
 # infrastructure: this typically means that we mirror only on the main and live branches.

 # Mirror the AWS CloudWatch agent image using the latest tag.
.copy:cloudwatch:dev:
  extends: .kaniko
  stage: copy
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  script:
    - mkdir -p /workspace
    - echo 'FROM amazon/cloudwatch-agent' >/workspace/Dockerfile
    - /kaniko/executor
      --context=/workspace
      --build-arg GIT_COMMIT=$CI_COMMIT_SHA
      --build-arg GIT_TAG=$CI_COMMIT_TAG
      --destination=$WEBCMS_REPO_URL/webcms-$WEBCMS_ENVIRONMENT-aws-cloudwatch
      --destination=$WEBCMS_REPO_URL_WEST/webcms-$WEBCMS_ENVIRONMENT-aws-cloudwatch
      --destination=$CI_REGISTRY_IMAGE/webcms-$WEBCMS_ENVIRONMENT-aws-cloudwatch
      
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev

# Build custom Traefik image based off the 2.4 tag. Use latest tag(Keep this as "latest" Traefik tag mentions found
# in terraform/infrastructure/traefik_service.tf and .buildkite/infrastructure.yml.)
.build:traefik:dev:
  extends: .kaniko
  stage: infrastructure_preprod_build
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  script:
    - /kaniko/executor
      $KANIKO_CACHE_ARGS
      --context=$CI_PROJECT_DIR/services/traefik
      --build-arg GIT_COMMIT=$CI_COMMIT_SHA
      --build-arg GIT_TAG=$CI_COMMIT_TAG
      --destination=$WEBCMS_REPO_URL/webcms-$WEBCMS_ENVIRONMENT-traefik:latest
      --destination=$WEBCMS_REPO_URL_WEST/webcms-$WEBCMS_ENVIRONMENT-traefik:latest
      --destination=$CI_REGISTRY_IMAGE/webcms-$WEBCMS_ENVIRONMENT-traefik:latest
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev

# Mirror the New Relic PHP daemon
.copy:newrelic:dev:
  extends: .kaniko
  stage: copy
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  script:
    - mkdir -p /workspace
    - echo 'FROM newrelic/php-daemon' >/workspace/Dockerfile
    - /kaniko/executor
      --context=/workspace
      --build-arg GIT_COMMIT=$CI_COMMIT_SHA
      --build-arg GIT_TAG=$CI_COMMIT_TAG
      --destination=$WEBCMS_REPO_URL/webcms-$WEBCMS_ENVIRONMENT-newrelic-daemon
      --destination=$WEBCMS_REPO_URL_WEST/webcms-$WEBCMS_ENVIRONMENT-newrelic-daemon
      --destination=$CI_REGISTRY_IMAGE/webcms-$WEBCMS_ENVIRONMENT-newrelic-daemon
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev

#endregion

Drupal:
  stage: Image Scan
  tags:
    - twistcli
  variables:
    GIT_STRATEGY: none
  script:
    - 'export PRISMA_CI_TOKEN=$(curl -kH "Content-Type: application/json" -d "{\"username\":\"$PRISMA_CI_USERNAME\", \"password\":\"$PRISMA_CI_PASSWORD\"}" https://prismacloud.epa.gov/api/v32.01/authenticate | jq -r .token)'
    - 'curl --progress-bar -L -k --header "Authorization: Bearer $PRISMA_CI_TOKEN" https://prismacloud.epa.gov/api/v1/util/twistcli > twistcli; chmod a+x twistcli;'
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE/webcms-preproduction-dev-drupal:$WEBCMS_IMAGE_TAG
    - ./twistcli images scan $CI_REGISTRY_IMAGE/webcms-preproduction-dev-drupal:$WEBCMS_IMAGE_TAG --address=https://prismacloud.epa.gov --details --token=$PRISMA_CI_TOKEN
  after_script:
    # Cleanup the above space use on Runner.
    - rm -rf $CI_PROJECT_DIR
  allow_failure: true

Nginx:
  stage: Image Scan
  tags:
    - twistcli
  variables:
    GIT_STRATEGY: none
  script:
    - 'export PRISMA_CI_TOKEN=$(curl -kH "Content-Type: application/json" -d "{\"username\":\"$PRISMA_CI_USERNAME\", \"password\":\"$PRISMA_CI_PASSWORD\"}" https://prismacloud.epa.gov/api/v32.01/authenticate | jq -r .token)'
    - 'curl --progress-bar -L -k --header "Authorization: Bearer $PRISMA_CI_TOKEN" https://prismacloud.epa.gov/api/v1/util/twistcli > twistcli; chmod a+x twistcli;'
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE/webcms-preproduction-dev-nginx:$WEBCMS_IMAGE_TAG
    - ./twistcli images scan $CI_REGISTRY_IMAGE/webcms-preproduction-dev-nginx:$WEBCMS_IMAGE_TAG --address=https://prismacloud.epa.gov --details --token=$PRISMA_CI_TOKEN
  after_script:
    # Cleanup the above space use on Runner.
    - rm -rf $CI_PROJECT_DIR
  allow_failure: true

Drush:
  stage: Image Scan
  tags:
    - twistcli
  variables:
    GIT_STRATEGY: none
  script:
    - 'export PRISMA_CI_TOKEN=$(curl -kH "Content-Type: application/json" -d "{\"username\":\"$PRISMA_CI_USERNAME\", \"password\":\"$PRISMA_CI_PASSWORD\"}" https://prismacloud.epa.gov/api/v32.01/authenticate | jq -r .token)'
    - 'curl --progress-bar -L -k --header "Authorization: Bearer $PRISMA_CI_TOKEN" https://prismacloud.epa.gov/api/v1/util/twistcli > twistcli; chmod a+x twistcli;'
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE/webcms-preproduction-dev-drush:$WEBCMS_IMAGE_TAG
    - ./twistcli images scan $CI_REGISTRY_IMAGE/webcms-preproduction-dev-drush:$WEBCMS_IMAGE_TAG --address=https://prismacloud.epa.gov --details --token=$PRISMA_CI_TOKEN
  after_script:
    # Cleanup the above space use on Runner.
    - rm -rf $CI_PROJECT_DIR
  allow_failure: true

Database:
  stage: Image Scan
  tags:
    - twistcli
  variables:
    GIT_STRATEGY: none
  script:
    - 'export PRISMA_CI_TOKEN=$(curl -kH "Content-Type: application/json" -d "{\"username\":\"$PRISMA_CI_USERNAME\", \"password\":\"$PRISMA_CI_PASSWORD\"}" https://prismacloud.epa.gov/api/v32.01/authenticate | jq -r .token)'
    - 'curl --progress-bar -L -k --header "Authorization: Bearer $PRISMA_CI_TOKEN" https://prismacloud.epa.gov/api/v1/util/twistcli > twistcli; chmod a+x twistcli;'
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE/webcms-preproduction-dev-terraform-database:$WEBCMS_IMAGE_TAG
    - ./twistcli images scan $CI_REGISTRY_IMAGE/webcms-preproduction-dev-terraform-database:latest --address=https://prismacloud.epa.gov --details --token=$PRISMA_CI_TOKEN
  after_script:
    # Cleanup the above space use on Runner.
    - rm -rf $CI_PROJECT_DIR
  allow_failure: true

.Metrics:
  stage: Image Scan
  tags:
    - twistcli
  variables:
    GIT_STRATEGY: none
  script:
    - 'export PRISMA_CI_TOKEN=$(curl -kH "Content-Type: application/json" -d "{\"username\":\"$PRISMA_CI_USERNAME\", \"password\":\"$PRISMA_CI_PASSWORD\"}" https://prismacloud.epa.gov/api/v32.01/authenticate | jq -r .token)'
    - 'curl --progress-bar -L -k --header "Authorization: Bearer $PRISMA_CI_TOKEN" https://prismacloud.epa.gov/api/v1/util/twistcli > twistcli; chmod a+x twistcli;'
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE/webcms-preproduction-dev-fpm-metrics:$WEBCMS_IMAGE_TAG
    - ./twistcli images scan $CI_REGISTRY_IMAGE/webcms-preproduction-dev-fpm-metrics:$WEBCMS_IMAGE_TAG --address=https://prismacloud.epa.gov --details --token=$PRISMA_CI_TOKEN
  after_script:
    # Cleanup the above space use on Runner.
    - rm -rf $CI_PROJECT_DIR
  allow_failure: true

.New Relic:
  stage: Image Scan
  tags:
    - twistcli
  variables:
    GIT_STRATEGY: none
  script:
    - 'export PRISMA_CI_TOKEN=$(curl -kH "Content-Type: application/json" -d "{\"username\":\"$PRISMA_CI_USERNAME\", \"password\":\"$PRISMA_CI_PASSWORD\"}" https://prismacloud.epa.gov/api/v32.01/authenticate | jq -r .token)'
    - 'curl --progress-bar -L -k --header "Authorization: Bearer $PRISMA_CI_TOKEN" https://prismacloud.epa.gov/api/v1/util/twistcli > twistcli; chmod a+x twistcli;'
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE/webcms-preproduction-newrelic-daemon
    - ./twistcli images scan $CI_REGISTRY_IMAGE/webcms-preproduction-newrelic-daemon --address=https://prismacloud.epa.gov --details --token=$PRISMA_CI_TOKEN
  after_script:
    # Cleanup the above space use on Runner.
    - rm -rf $CI_PROJECT_DIR
  allow_failure: true

.Traefik:
  stage: Image Scan
  tags:
    - twistcli
  variables:
    GIT_STRATEGY: none
  script:
    - 'export PRISMA_CI_TOKEN=$(curl -kH "Content-Type: application/json" -d "{\"username\":\"$PRISMA_CI_USERNAME\", \"password\":\"$PRISMA_CI_PASSWORD\"}" https://prismacloud.epa.gov/api/v32.01/authenticate | jq -r .token)'
    - 'curl --progress-bar -L -k --header "Authorization: Bearer $PRISMA_CI_TOKEN" https://prismacloud.epa.gov/api/v1/util/twistcli > twistcli; chmod a+x twistcli;'
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE/webcms-preproduction-traefik:latest
    - ./twistcli images scan $CI_REGISTRY_IMAGE/webcms-preproduction-traefik:latest --address=https://prismacloud.epa.gov --details --token=$PRISMA_CI_TOKEN
  after_script:
    # Cleanup the above space use on Runner.
    - rm -rf $CI_PROJECT_DIR
  allow_failure: true

.CloudWatch:
  stage: Image Scan
  tags:
    - twistcli
  variables:
    GIT_STRATEGY: none
  script:
    - 'export PRISMA_CI_TOKEN=$(curl -kH "Content-Type: application/json" -d "{\"username\":\"$PRISMA_CI_USERNAME\", \"password\":\"$PRISMA_CI_PASSWORD\"}" https://prismacloud.epa.gov/api/v32.01/authenticate | jq -r .token)'
    - 'curl --progress-bar -L -k --header "Authorization: Bearer $PRISMA_CI_TOKEN" https://prismacloud.epa.gov/api/v1/util/twistcli > twistcli; chmod a+x twistcli;'
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull $CI_REGISTRY_IMAGE/webcms-preproduction-aws-cloudwatch
    - ./twistcli images scan $CI_REGISTRY_IMAGE/webcms-preproduction-aws-cloudwatch --address=https://prismacloud.epa.gov --details --token=$PRISMA_CI_TOKEN
  after_script:
    # Cleanup the above space use on Runner.
    - rm -rf $CI_PROJECT_DIR
  allow_failure: true


#region Preproduction

# Jobs in this region affect the preproduction environment. Per convention, the
# preproduction environment encompasses two sites: development and staging, hence
# the subregions below the infrastructure step.

# Preproduction infrastructure builds are triggered only by the 'live' branch.
infrastructure:preproduction:init:
  extends: .infrastructure
  stage: infrastructure_preprod_init
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    TF_STATE_NAME: dev
  script:
    - gitlab-terraform init -upgrade
    - gitlab-terraform init
  environment:
    name: infra/preproduction

infrastructure:preproduction:validate:
  extends: .infrastructure
  stage: infrastructure_preprod_validate
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    TF_STATE_NAME: dev
  script:
    - gitlab-terraform init -upgrade
    - gitlab-terraform validate
  environment:
    name: infra/preproduction

infrastructure:preproduction:plan:
  extends: .infrastructure
  stage: infrastructure_preprod_plan
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    TF_STATE_NAME: dev
  script:
    - gitlab-terraform init -upgrade
    - gitlab-terraform plan
    - gitlab-terraform plan-json
  timeout: 24h
  environment:
    name: infra/preproduction
  artifacts:
    name: plan
    paths:
      - $TF_ROOT/plan.cache
    reports:
      terraform: $TF_ROOT/plan.json

infrastructure:preproduction:apply:
  extends: .infrastructure
  stage: infrastructure_preprod_apply
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  dependencies: ["infrastructure:preproduction:plan"]
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    TF_STATE_NAME: dev
  script:
    - gitlab-terraform init -upgrade
    - gitlab-terraform apply
  environment:
    name: infra/preproduction

#sub-region us-west-2: 
# These steps deploy into the infra/preproduction-west environment
# the infra/preproduction-west environment is pointed to the us-west-2 region within the DrupalCloud AWS accounts
infrastructure:preproduction-west:init:
  extends: .infrastructure
  stage: infrastructure_preprod_west_init
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    TF_STATE_NAME: dev-west
    #override the TF_ADDRESS in .infrastructure
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-west
  script:
    - gitlab-terraform init -upgrade
    - gitlab-terraform init
  environment:
    name: infra/preproduction-west

infrastructure:preproduction-west:validate:
  extends: .infrastructure
  stage: infrastructure_preprod_west_validate
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    TF_STATE_NAME: dev-west
    #override the TF_ADDRESS in .infrastructure
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-west
  script:
    - gitlab-terraform init -upgrade
    - gitlab-terraform validate
  environment:
    name: infra/preproduction-west

infrastructure:preproduction-west:plan:
  extends: .infrastructure
  stage: infrastructure_preprod_west_plan
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    TF_STATE_NAME: dev-west
    #override the TF_ADDRESS in .infrastructure
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-west
  script:
    - gitlab-terraform init -upgrade
    - gitlab-terraform plan
    - gitlab-terraform plan-json
  timeout: 24h 
  environment:
    name: infra/preproduction-west
  artifacts:
    name: plan
    paths:
      - $TF_ROOT/plan.cache
    reports:
      terraform: $TF_ROOT/plan.json

infrastructure:preproduction-west:apply:
  extends: .infrastructure
  stage: infrastructure_preprod_west_apply
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  dependencies: ["infrastructure:preproduction-west:plan"]
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    TF_STATE_NAME: dev-west
    #override the TF_ADDRESS in .infrastructure
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-west
  script:
    - gitlab-terraform init -upgrade
    - gitlab-terraform apply
  environment:
    name: infra/preproduction-west























deploy:dev:init:en:
  extends: .deploy
  stage: deploy:dev:init:en
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_LANG: en
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    TF_STATE_NAME: dev-webcms-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-$WEBCMS_LANG
  environment:
    name: site/dev-$WEBCMS_LANG

  script:
    - echo $TF_ADDRESS
    - gitlab-terraform init

deploy:dev:init:es:
  extends: .deploy
  stage: deploy:dev:init:es
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_LANG: es
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    TF_STATE_NAME: dev-webcms-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-$WEBCMS_LANG
  environment:
    name: site/dev-$WEBCMS_LANG

  script:
    - echo $TF_ADDRESS
    - gitlab-terraform init


# Validate syntax and configuration
deploy:dev:validate:en:
  extends: .deploy
  stage: deploy:dev:validate:en
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: en
    TF_STATE_NAME: dev-webcms-$WEBCMS_LANG

  environment:
    name: site/dev-$WEBCMS_LANG
  script:
    - gitlab-terraform validate

# Validate syntax and configuration
deploy:dev:validate:es:
  extends: .deploy
  stage: deploy:dev:validate:es
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: en
    TF_STATE_NAME: dev-webcms-$WEBCMS_LANG
  environment:
    name: site/dev-$WEBCMS_LANG
  script:
    - gitlab-terraform validate

# Perform a plan, uploading the plan files as GitLab artifacts.
deploy:dev:plan-en:
  extends: .deploy
  stage: deploy:dev:plan:en
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: en
    TF_STATE_NAME: dev-webcms-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-$WEBCMS_LANG
  environment:
    name: site/dev-$WEBCMS_LANG

  script:
    - gitlab-terraform plan
    - gitlab-terraform plan-json

  artifacts:
    name: plan
    paths:
      - $TF_ROOT/plan.cache
    reports:
      terraform: $TF_ROOT/plan.json

deploy:dev:plan-es:
  extends: .deploy
  stage: deploy:dev:plan:es
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: es
    TF_STATE_NAME: dev-webcms-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-$WEBCMS_LANG
  environment:
    name: site/dev-$WEBCMS_LANG

  script:
    - gitlab-terraform plan
    - gitlab-terraform plan-json

  artifacts:
    name: plan
    paths:
      - $TF_ROOT/plan.cache
    reports:
      terraform: $TF_ROOT/plan.json


# Perform an apply. Note that this is not always automatic; see the comments above the rules
# for more.
deploy:dev:apply-en:
  extends: .deploy
  stage: deploy:dev:apply:en

  # Download the plan files from the previous step.
  dependencies: ["deploy:dev:plan-en"]

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: en
    TF_STATE_NAME: dev-webcms-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-$WEBCMS_LANG
  environment:
    name: site/dev-$WEBCMS_LANG

  script:
    - gitlab-terraform apply

  # We use GitLab's rules to limit when we block the application of a Terraform module.
  #
  # There are three rules:
  # 1. We require approval of the infrastructure module on its tracking branches (main and
  #    live).
  # 2. We permit automatic application of the webcms module, since it only updates a
  #    limited subset of ECS resources.
  # 3. Any other attempt to apply a Terraform plan is explicitly denied. This is provided
  #    as a safety net to keep misconfigured trigger jobs from accidentally clobbering
  #    live AWS resources.
  #
  # NB. GitLab uses a "first match wins" order of rule evaluation, which is why the third
  # rule does not have an `if:` condition limiting when it applies.
  rules:
    - if: >-
        $TF_MODULE == "infrastructure" &&
        ($CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
      when: manual
    - if: >-
        $TF_MODULE == "webcms" &&
        ($CI_COMMIT_BRANCH == "integration" || $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
      when: on_success

    - when: never

deploy:dev:apply-es:
  extends: .deploy
  stage: deploy:dev:apply:es

  # Download the plan files from the previous step.
  dependencies: ["deploy:dev:plan-es"]

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: es
    TF_STATE_NAME: dev-webcms-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-$WEBCMS_LANG
  environment:
    name: site/dev-$WEBCMS_LANG

  script:
    - gitlab-terraform apply

  # We use GitLab's rules to limit when we block the application of a Terraform module.
  #
  # There are three rules:
  # 1. We require approval of the infrastructure module on its tracking branches (main and
  #    live).
  # 2. We permit automatic application of the webcms module, since it only updates a
  #    limited subset of ECS resources.
  # 3. Any other attempt to apply a Terraform plan is explicitly denied. This is provided
  #    as a safety net to keep misconfigured trigger jobs from accidentally clobbering
  #    live AWS resources.
  #
  # NB. GitLab uses a "first match wins" order of rule evaluation, which is why the third
  # rule does not have an `if:` condition limiting when it applies.
  rules:
    - if: >-
        $TF_MODULE == "infrastructure" &&
        ($CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
      when: manual
    - if: >-
        $TF_MODULE == "webcms" &&
        ($CI_COMMIT_BRANCH == "integration" || $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
      when: on_success

    - when: never

#endregion






#region:  US West 2 deployment
deploy:dev-west:init:en:
  extends: .deploy
  stage: deploy:dev-west:init:en
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_LANG: en
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    TF_STATE_NAME: dev-webcms-west-$WEBCMS_LANG
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-webcms-west-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-west-$WEBCMS_LANG
  environment:
    name: site/dev-west-$WEBCMS_LANG

  script:
    - echo $TF_ADDRESS
    - gitlab-terraform init

deploy:dev-west:init:es:
  extends: .deploy
  stage: deploy:dev-west:init:es
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_LANG: es
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    TF_STATE_NAME: dev-webcms-west-$WEBCMS_LANG
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-webcms-west-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-west-$WEBCMS_LANG
  environment:
    name: site/dev-west-$WEBCMS_LANG

  script:
    - echo $TF_ADDRESS
    - gitlab-terraform init


# Validate syntax and configuration
deploy:dev-west:validate:en:
  extends: .deploy
  stage: deploy:dev-west:validate:en
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: en
    TF_STATE_NAME: dev-webcms-west-$WEBCMS_LANG
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-webcms-west-$WEBCMS_LANG

  environment:
    name: site/dev-west-$WEBCMS_LANG
  script:
    - gitlab-terraform validate

# Validate syntax and configuration
deploy:dev-west:validate:es:
  extends: .deploy
  stage: deploy:dev-west:validate:es
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: en
    TF_STATE_NAME: dev-webcms-west-$WEBCMS_LANG
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-webcms-west-$WEBCMS_LANG
  environment:
    name: site/dev-west-$WEBCMS_LANG
  script:
    - gitlab-terraform validate

# Perform a plan, uploading the plan files as GitLab artifacts.
deploy:dev-west:plan-en:
  extends: .deploy
  stage: deploy:dev-west:plan:en
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: en
    TF_STATE_NAME: dev-webcms-west-$WEBCMS_LANG
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-webcms-west-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-west-$WEBCMS_LANG
  environment:
    name: site/dev-west-$WEBCMS_LANG

  script:
    - gitlab-terraform plan
    - gitlab-terraform plan-json

  artifacts:
    name: plan
    paths:
      - $TF_ROOT/plan.cache
    reports:
      terraform: $TF_ROOT/plan.json

deploy:dev-west:plan-es:
  extends: .deploy
  stage: deploy:dev-west:plan:es
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: es
    TF_STATE_NAME: dev-webcms-$WEBCMS_LANG
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-webcms-west-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-west-$WEBCMS_LANG
  environment:
    name: site/dev-west-$WEBCMS_LANG

  script:
    - gitlab-terraform plan
    - gitlab-terraform plan-json

  artifacts:
    name: plan
    paths:
      - $TF_ROOT/plan.cache
    reports:
      terraform: $TF_ROOT/plan.json


# Perform an apply. Note that this is not always automatic; see the comments above the rules
# for more.
deploy:dev-west:apply-en:
  extends: .deploy
  stage: deploy:dev-west:apply:en

  # Download the plan files from the previous step.
  dependencies: ["deploy:dev-west:plan-en"]

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: en
    TF_STATE_NAME: dev-webcms-$WEBCMS_LANG
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-webcms-west-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-west-$WEBCMS_LANG
  environment:
    name: site/dev-west-$WEBCMS_LANG

  script:
    - gitlab-terraform apply

  # We use GitLab's rules to limit when we block the application of a Terraform module.
  #
  # There are three rules:
  # 1. We require approval of the infrastructure module on its tracking branches (main and
  #    live).
  # 2. We permit automatic application of the webcms module, since it only updates a
  #    limited subset of ECS resources.
  # 3. Any other attempt to apply a Terraform plan is explicitly denied. This is provided
  #    as a safety net to keep misconfigured trigger jobs from accidentally clobbering
  #    live AWS resources.
  #
  # NB. GitLab uses a "first match wins" order of rule evaluation, which is why the third
  # rule does not have an `if:` condition limiting when it applies.
  rules:
    - if: >-
        $TF_MODULE == "infrastructure" &&
        ($CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
      when: manual

    - if: >-
        $TF_MODULE == "webcms" &&
        ($CI_COMMIT_BRANCH == "integration" || $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
      when: on_success

    - when: never

deploy:dev-west:apply-es:
  extends: .deploy
  stage: deploy:dev-west:apply:es

  # Download the plan files from the previous step.
  dependencies: ["deploy:dev-west:plan-es"]

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: es
    TF_STATE_NAME: dev-webcms-$WEBCMS_LANG
    TF_ADDRESS: ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/terraform/state/dev-webcms-west-$WEBCMS_LANG

  # As mentioned in the comments on the infrastructure:preproduction job, we use a
  # resource group to prevent overlapping Terraform runs. The environment names here are
  # prefixed with "site/" to indicate that they're for the Drupal site instead of
  # infrastructure.
  resource_group: site/dev-west-$WEBCMS_LANG
  environment:
    name: site/dev-west-$WEBCMS_LANG

  script:
    - gitlab-terraform apply

  # We use GitLab's rules to limit when we block the application of a Terraform module.
  #
  # There are three rules:
  # 1. We require approval of the infrastructure module on its tracking branches (main and
  #    live).
  # 2. We permit automatic application of the webcms module, since it only updates a
  #    limited subset of ECS resources.
  # 3. Any other attempt to apply a Terraform plan is explicitly denied. This is provided
  #    as a safety net to keep misconfigured trigger jobs from accidentally clobbering
  #    live AWS resources.
  #
  # NB. GitLab uses a "first match wins" order of rule evaluation, which is why the third
  # rule does not have an `if:` condition limiting when it applies.
  rules:
    - if: >-
        $TF_MODULE == "infrastructure" &&
        ($CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
      when: manual

    - if: >-
        $TF_MODULE == "webcms" &&
        ($CI_COMMIT_BRANCH == "integration" || $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
      when: on_success

    - when: never





.deploy:stage:init:
  extends: .deploy
  stage: deploy:stage:init
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  when: manual

  parallel:
    matrix:
      - WEBCMS_LANG: [en, es]

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: stage
    TF_STATE_NAME: stage-webcms-$WEBCMS_LANG

  resource_group: site/stage-$WEBCMS_LANG
  environment:
    name: site/stage-$WEBCMS_LANG

  script:
    - gitlab-terraform init

# Validate syntax and configuration
.deploy:stage:validate:
  extends: .deploy
  stage: deploy:stage:validate
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'
  when: manual

  parallel:
    matrix:
      - WEBCMS_LANG: [en, es]

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: stage
    TF_STATE_NAME: stage-webcms-$WEBCMS_LANG

  resource_group: site/stage-$WEBCMS_LANG
  environment:
    name: site/stage-$WEBCMS_LANG

  script:
    - gitlab-terraform validate

# Perform a plan, uploading the plan files as GitLab artifacts.
.deploy:stage:plan:
  extends: .deploy
  stage: deploy:stage:plan
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  when: manual

  parallel:
    matrix:
      - WEBCMS_LANG: [en, es]

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: stage
    TF_STATE_NAME: stage-webcms-$WEBCMS_LANG

  resource_group: site/stage-$WEBCMS_LANG
  environment:
    name: site/stage-$WEBCMS_LANG

  script:
    - gitlab-terraform plan
    - gitlab-terraform plan-json

  artifacts:
    name: plan
    paths:
      - $TF_ROOT/plan.cache
    reports:
      terraform: $TF_ROOT/plan.json

# Perform an apply. Note that this is not always automatic; see the comments above the rules
# for more.
.deploy:stage:apply:
  extends: .deploy
  stage: deploy:stage:apply

  # Download the plan files from the previous step.
  dependencies: ["deploy:dev:plan"]

  parallel:
    matrix:
      - WEBCMS_LANG: [en, es]

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: stage
    TF_STATE_NAME: stage-webcms-$WEBCMS_LANG

  resource_group: site/stage-$WEBCMS_LANG
  environment:
    name: site/stage-$WEBCMS_LANG

  script:
    - gitlab-terraform apply

  when: manual

  # We use GitLab's rules to limit when we block the application of a Terraform module.
  #
  # There are three rules:
  # 1. We require approval of the infrastructure module on its tracking branches (main and
  #    live).
  # 2. We permit automatic application of the webcms module, since it only updates a
  #    limited subset of ECS resources.
  # 3. Any other attempt to apply a Terraform plan is explicitly denied. This is provided
  #    as a safety net to keep misconfigured trigger jobs from accidentally clobbering
  #    live AWS resources.
  #
  # NB. GitLab uses a "first match wins" order of rule evaluation, which is why the third
  # rule does not have an `if:` condition limiting when it applies.
#   rules:
#     - if: >-
#         $TF_MODULE == "infrastructure" &&
#         ($CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
#       when: manual

#     - if: >-
#         $TF_MODULE == "webcms" &&
#         ($CI_COMMIT_BRANCH == "integration" || $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "live")
#       when: on_success

#     - when: never

#endregion









update:dev:en:
  extends: .update
  stage: update:en
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: en

  # Note that while we want to prevent overlapping Drush runs, we don't also include an
  # environment here because, like the Docker image builds, there are no inputs outside
  # of the provided $WEBCMS_* variables.
  resource_group: drush/dev-$WEBCMS_LANG
  environment:
    name: site/dev-$WEBCMS_LANG

update:dev:es:
  extends: .update
  stage: update:es
  rules:
    - if: '$CI_COMMIT_BRANCH == "live"'

  variables:
    WEBCMS_ENVIRONMENT: preproduction
    WEBCMS_SITE: dev
    WEBCMS_LANG: es

  # Note that while we want to prevent overlapping Drush runs, we don't also include an
  # environment here because, like the Docker image builds, there are no inputs outside
  # of the provided $WEBCMS_* variables.
  resource_group: drush/dev-$WEBCMS_LANG
  environment:
    name: site/dev-$WEBCMS_LANG

###################
# Create Releases #
###################

# Create artifacts of ci, terraform/database, terraform/infrastructure, and terraform/webcms directories
# Only run if CI_COMMIT_TAG is defined
Artifacts:
  image: alpine
  stage: artifacts
  rules:
    - if: $CI_COMMIT_TAG != ""
      when: always
    - if: '$CI_COMMIT_BRANCH == "live"'
  script:
    - echo "Creating artifacts"
  artifacts:
    paths:
      - ./ci
      - ./terraform/infrastructure
      - ./terraform/webcms