С чего все началось

За более 3х летний срок существования продукта у нас собралось более чем 20 репозиториев со spark проектами. Процесс CICD был реализован на Jenkins. С определенного момента у GitLab CI появилась возможность создавать собственные CICD. Но долгое время я совершенно не воспринимал всерьез этот инструмент. Так как мне нравилось, что в Jenkins можно взять и дописать то чего тебе не хватает на Groovy. Настройка WebUI предоставляет широкие возможности для организации параметризованных сборок. Поначалу функционал GitlabCI я воспринимал это как жалкое подобие Jenkins: чтобы реализовать ну что-то очень очевидное и простое, я уже молчу про параметризованную сборку.

Но прошло время и мне показали как возможно шарить между проектами джобы, чтобы реализация под конкретный проект выглядела с наименьшим количеством кода.

Для примера у вас где-то в отдельном репозитории лежат yml, которые выполняют что-то вполне определенное, которое у вас может повторяться не только в одном проекте.

    include:
    - project: 'gitlabci/cicd'
    ref: v1
    file:
      - 'pipelines/product1/.base_pipelines_spark_project.yml'

Выполнять include какого-то джоба у себя в конвейере и прям стало одной из киллер фич. И в какой-то момент перевод пайплайн на GitLabCI уже не выглядело как необходимость, а собственным желанием реализовать интересную задачу.

Что было

• более 20 репозиториев в gitlab spark проектов;

• часть из них работают со spark часть из них spark + kafka;

• CICD реализован на Jenkins

Что хотелось сделать

Выполнить трансформацию CICD с Jenkins на Gitlab CI c наименьшим количеством шагов: чтобы команда разработки, если хотела бы вникнуть то могла это сделать, а если нет то было бы что-нибудь типа создать такой-то файл и скопировать туда такой-то yaml код и чтобы гарантированно заработало причем без активной помощи со стороны devops разработчика.

Начало

В каждом из Spark проектов реализовано было тестирование по одному из 2-х сценариев: с кафка или без. Описать сценарий в одном job было не возможно и поэтому были созданы 2 yaml, которые подключались следующим образом

    include:
      # PRODUCT1
      - project: 'gitlabci/integration-test'
      ref: v2
      file:
        - 'product1/etl/.base_integration_test.yml'
        - 'product1/etl/.base_integration_test_with_kafka.yml'

Для того, чтобы .gitlab-ci.yml выглядел для каждого проекта одинаковым необходимо было придумать логику таким образом, чтобы пайплайн на основании семантического анализа кода в test/fixtures.py мог определить какой сценарий необходим. Решить эту задачу оказалось достаточно тривиальной задачей, первая проблема была дальше. Предполагалось создать job, который в процессе анализа определял переменную CICD_KAFKA_HOST либо в true либо в false

    prepare_test:
      script:
        - export CICD_KAFKA_HOST=$(cat test/fixtures.py | grep KAFKA_HOST)
        - >
          if [ "$CICD_KAFKA_HOST" != "" ]; then
            export CICD_KAFKA_HOST="true"
          else
            export CICD_KAFKA_HOST="false"
          fi
        - echo "CICD_KAFKA_HOST=$CICD_KAFKA_HOST" >> dotenv.env
      artifacts:
        reports:
          dotenv:
            - dotenv.env

и в последующих job нужно запускать тесты либо c кафка либо без. Но по ходу реализации выяснилось, что использовать rules нельзя, потому variables для rules определяются при старте пайплайна и не могут быть переопределены/изменены в процессе работы конвейера и расширения extends должны быть определены в пайплайне однозначным образом.

    integration_test:
      extends: .base_integration_test_with_kafka
      rules:
        - if: '$CICD_KAFKA_HOST == "true"'

Реализация идеи "smart" пайплайна первый раз подверглась сомнению. НО по на помощь должны были прийти триггеры.

Триггер

Триггер предоставляет возможность запустить в текущем пайплайне другой пайплайн. Текущий пайплайн становится родительским, а запускаемый другой пайплан ребенком.

Реализация получилась такой

    # --------------- Prepare Test --------------- 
    prepare_test:
      image: platform/docker-images/vault:1.8
      variables:
        CONTEXT_TEST: |
          include:
          # PRODUCT
          - project: 'gitlabci/integration-test'
            ref: v2
            file:
              - 'product1/etl/.base_integration_test.yml'
              - 'product1/etl/.base_integration_test_with_kafka.yml'
          integration_test:
            variables:
              COVERAGE_SOURCE: "./src"
        INTEGRATION_TEST: |
          $CONTEXT_TEST
            extends: .base_integration_test
        INTEGRATION_TEST_WITH_KAFKA: |
          $CONTEXT_TEST
            extends: .base_integration_test_with_kafka

    stage: prepare_test
      script:
        - export CICD_KAFKA_HOST=$(cat test/fixtures.py | grep KAFKA_HOST)
        - >
          if [ "$CICD_KAFKA_HOST" != "" ]; then
            export CICD_KAFKA_HOST="true"
            echo "$INTEGRATION_TEST_WITH_KAFKA" >> test.yml
          else
            export CICD_KAFKA_HOST="false"
            echo "$INTEGRATION_TEST" >> test.yml
          fi
        - env | sort -f
      artifacts:
        paths:
          - test.yml
        expire_in: 7200 seconds

    # --------------- Integration test --------------- 
    integration_test:
      stage: test
      trigger:
        include:
          - artifact: test.yml
            job: prepare_test
        strategy: depend

В такой реализации обычный пайплайн трансформировался в мультипайплайн: родительский пайплайн инициировал запуск пайплайна-ребенка

Такие образом появилось smart начало: он умеет определять какой сценарий выбрать и в job с интеграционным тестированием переиспользует именно тот сценарий который необходим: либо с кафка либо без. Начало положено, НО возникла проблема №2: результатом выполнения pipeline ребенка - формирование coverage отчета, который не мультипайплайнах мы далее передаем в job c SonarQube. Решить задачу по передаче между job artifact в виде файлов как раньше было нельзя, вернуть artifact из child в parent оказалось невозможно.

Очевидное решение - добавить upload artifact в наш aftifactory и в job c SonarQube просто его скачать. Но хотелось найти более изящный способ, чтобы исключить дополнительные обращения к Artifactory. И способ был найден: Gitlab CI API

Gitlab CI API: download child artifacts

Чтобы иметь возможность подключаться к Gitlab CI API необходимо для пользователя, который имеет права на репозиторий сгенерировать token. Для того чтобы воспользоваться API скачать artifact из pipeline ребенка необходимо выяснить его CI_JOB_ID.

GET /projects/:id/jobs/:job_id/artifacts

Как это сделать из pipeline родителя?

- определяем ID pipeline ребенка

GET /projects/:id/pipelines/:pipeline_id/bridges

- по id pipeline ребенка определяем id job

GET /projects/:id/pipelines/:pipeline_id/jobs

- после этого уже выполняем скачивание методом /projects/:id/jobs/:job_id/artifacts

Итоговая реализация job по скачиванию artifacts будет выглядеть так: в список переменных группы проектов куда входит и наш репозиторий положили значение token - GITLAB_USER_TOKEN и для разбора json ответа от Gitlab API использовали jq

    get_cicd_artifact:
      image: platform/docker-images/ansible:2.9.24-9
      stage: get_cicd_artifact
      script:
        - >
          export CI_CHILD_PIPELINE_ID=$(curl --header "PRIVATE-TOKEN: $GITLAB_USER_TOKEN" "$CI_API_V4_URL/projects/$CI_PROJECT_ID/pipelines/$CI_PIPELINE_ID/bridges" | jq ".[].downstream_pipeline.id")
        - echo $CI_CHILD_PIPELINE_ID
        - >
          export CI_CHILD_JOB_ID=$(curl --header "PRIVATE-TOKEN: $GITLAB_USER_TOKEN" "$CI_API_V4_URL/projects/$CI_PROJECT_ID/pipelines/$CI_CHILD_PIPELINE_ID/jobs" | jq '.[].id')
        - echo $CI_CHILD_JOB_ID
        - 'curl --output artifacts.zip --header "PRIVATE-TOKEN: $GITLAB_USER_TOKEN" "$CI_API_V4_URL/projects/$CI_PROJECT_ID/jobs/$CI_CHILD_JOB_ID/artifacts"'
        - unzip artifacts.zip
        - ls -las coverage-reports
        - rm -rf artifacts.tar
      dependencies:
        - integration_test
      artifacts:
        paths:
          - coverage-reports/

Таким образом удалось реализовать Multi-project пайплайн имхо со "smart" фичой