Хабрахабр

JUnit в GitLab CI с Kubernetes

Несмотря на то, что все прекрасно знают, что тестировать свой софт важно и нужно, а многие давно делают это автоматически, на просторах Хабра не нашлось ни одного рецепта по настройке связки таких популярных в этой нише продуктов, как (любимый нами) GitLab и JUnit. Восполним этот пробел!

Вводные

Для начала обозначу контекст:

  • Так как все наши приложения работают в Kubernetes, будет рассмотрен запуск тестов в соответствующей инфраструктуре.
  • Для сборки и деплоя мы используем werf (в смысле инфраструктурных компонентов это также автоматически означает, что задействован Helm).
  • В детали непосредственного создания тестов вдаваться не буду: в нашем случае клиент пишет тесты сам, а мы лишь обеспечиваем их запуск (и наличие соответствующего отчета в merge request'е).

Как будет выглядеть общая последовательность действий?

  1. Сборка приложения — описание этого этапа мы опустим.
  2. Деплой приложения в отдельный namespace кластера Kubernetes и запуск тестирования.
  3. Поиск артефактов и парсинг JUnit-отчета GitLab’ом.
  4. Удаление созданного ранее namespace’а.

Теперь — к реализации!

Настройка

GitLab CI

Начнем с фрагмента .gitlab-ci.yaml, описывающего деплой приложения и запуск тестов. Листинг получился довольно объемным, поэтому основательно дополнен комментариями:

variables:
# объявляем версию werf, которую собираемся использовать WERF_VERSION: "1.0 beta" .base_deploy: &base_deploy script:
# создаем namespace в K8s, если его нет - kubectl --context="$" get ns ${CI_ENVIRONMENT_SLUG} || kubectl create ns ${CI_ENVIRONMENT_SLUG}
# загружаем werf и деплоим — подробнее об этом см. в документации
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#deploy-stage) - type multiwerf && source <(multiwerf use ${WERF_VERSION}) - werf version - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose) - werf deploy --stages-storage :local --namespace ${CI_ENVIRONMENT_SLUG} --set "global.commit_ref_slug=${CI_COMMIT_REF_SLUG:-''}"
# передаем переменную `run_tests`
# она будет использоваться в рендере Helm-релиза --set "global.run_tests=${RUN_TESTS:-no}" --set "global.env=${CI_ENVIRONMENT_SLUG}"
# изменяем timeout (бывают долгие тесты) и передаем его в релиз --set "global.ci_timeout=${CI_TIMEOUT:-900}" --timeout ${CI_TIMEOUT:-900} dependencies: - Build .test-base: &test-base extends: .base_deploy before_script:
# создаем директорию для будущего отчета, исходя из $CI_COMMIT_REF_SLUG - mkdir /mnt/tests/${CI_COMMIT_REF_SLUG} || true
# вынужденный костыль, т.к. GitLab хочет получить артефакты в своем build-dir’е - mkdir ./tests || true - ln -s /mnt/tests/${CI_COMMIT_REF_SLUG} ./tests/${CI_COMMIT_REF_SLUG} after_script:
# после окончания тестов удаляем релиз вместе с Job’ом
# (и, возможно, его инфраструктурой) - type multiwerf && source <(multiwerf use ${WERF_VERSION}) - werf version - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose) - werf dismiss --namespace ${CI_ENVIRONMENT_SLUG} --with-namespace
# мы разрешаем падения, но вы можете сделать иначе allow_failure: true variables: RUN_TESTS: 'yes'
# задаем контекст в werf
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#infrastructure) WERF_KUBE_CONTEXT: 'admin@stage-cluster' tags:
# используем раннер с тегом `werf-runner` - werf-runner artifacts:
# требуется собрать артефакт для того, чтобы его можно было увидеть
# в пайплайне и скачать — например, для более вдумчивого изучения paths: - ./tests/${CI_COMMIT_REF_SLUG}/*
# артефакты старше недели будут удалены expire_in: 7 day
# важно: эти строки отвечают за парсинг отчета GitLab’ом reports: junit: ./tests/${CI_COMMIT_REF_SLUG}/report.xml # для упрощения здесь показаны всего две стадии
# в реальности же у вас их будет больше — как минимум из-за деплоя
stages: - build - tests build: stage: build script:
# сборка — снова по документации по werf
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#build-stage) - type multiwerf && source <(multiwerf use ${WERF_VERSION}) - werf version - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose) - werf build-and-publish --stages-storage :local tags: - werf-runner except: - schedules run tests: <<: *test-base environment:
# "сама соль" именования namespace’а
# (https://docs.gitlab.com/ce/ci/variables/predefined_variables.html) name: tests-${CI_COMMIT_REF_SLUG} stage: tests except: - schedules

Kubernetes

Теперь в директории .helm/templates создадим YAML с Job’ом — tests-job.yaml — для запуска тестов и необходимыми ему ресурсами Kubernetes. Пояснения см. после листинга:

{{- if eq .Values.global.run_tests "yes" }}
---
apiVersion: v1
kind: ConfigMap
metadata: name: tests-script
data: tests.sh: | echo "======================" echo "${APP_NAME} TESTS" echo "======================" cd /app npm run test:ci cp report.xml /app/test_results/${CI_COMMIT_REF_SLUG}/ echo "" echo "" echo "" chown -R 999:999 /app/test_results/${CI_COMMIT_REF_SLUG}
---
apiVersion: batch/v1
kind: Job
metadata: name: {{ .Chart.Name }}-test annotations: "helm.sh/hook": post-install,post-upgrade "helm.sh/hook-weight": "2" "werf/watch-logs": "true"
spec: activeDeadlineSeconds: {{ .Values.global.ci_timeout }} backoffLimit: 1 template: metadata: name: {{ .Chart.Name }}-test spec: containers: - name: test command: ['bash', '-c', '/app/tests.sh']
{{ tuple "application" . | include "werf_container_image" | indent 8 }} env: - name: env value: {{ .Values.global.env }} - name: CI_COMMIT_REF_SLUG value: {{ .Values.global.commit_ref_slug }} - name: APP_NAME value: {{ .Chart.Name }}
{{ tuple "application" . | include "werf_container_env" | indent 8 }} volumeMounts: - mountPath: /app/test_results/ name: data - mountPath: /app/tests.sh name: tests-script subPath: tests.sh tolerations: - key: dedicated operator: Exists - key: node-role.kubernetes.io/master operator: Exists restartPolicy: OnFailure volumes: - name: data persistentVolumeClaim: claimName: {{ .Chart.Name }}-pvc - name: tests-script configMap: name: tests-script
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata: name: {{ .Chart.Name }}-pvc
spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Mi storageClassName: {{ .Chart.Name }}-{{ .Values.global.commit_ref_slug }} volumeName: {{ .Values.global.commit_ref_slug }} ---
apiVersion: v1
kind: PersistentVolume
metadata: name: {{ .Values.global.commit_ref_slug }}
spec: accessModes: - ReadWriteOnce capacity: storage: 10Mi local: path: /mnt/tests/ nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - kube-master persistentVolumeReclaimPolicy: Delete storageClassName: {{ .Chart.Name }}-{{ .Values.global.commit_ref_slug }}
{{- end }}

Что за ресурсы описаны в этой конфигурации? При деплое создаем уникальный для проекта namespace (это указано еще в .gitlab-ci.yamltests-${CI_COMMIT_REF_SLUG}) и в него выкатываем:

  1. ConfigMap со скриптом теста;
  2. Job с описанием pod’а и указанной директивой command, которая как раз и запускает тесты;
  3. PV и PVC, что позволяют хранить данные тестов.

Обратите внимание на вводное условие с if в начале манифеста — соответственно, другие YAML-файлы Helm-чарта с приложением надо обернуть в обратную конструкцию, чтобы они не деплоились при тестировании. То есть:

{{- if ne .Values.global.run_tests "yes" }}
---
я другой ямлик
{{- end }}

Впрочем, если тесты требуют некоторую инфраструктуру (например, Redis, RabbitMQ, Mongo, PostgreSQL…) — их YAML’ы можно не выключать. Разверните и их в тестовой среде… конечно же, подправив по своему усмотрению.

Финальный штрих

Т.к. сборка и деплой с помощью werf пока что работает только на build-сервере (с gitlab-runner), а pod с тестами запускается на мастере, потребуется создать директорию /mnt/tests на мастере и отдать ее на runner, например, по NFS. Развернутый пример с пояснениями можно найти в документации K8s.

Результатом станет:

user@kube-master:~$ cat /etc/exports | grep tests
/mnt/tests IP_gitlab-builder/32(rw,nohide,insecure,no_subtree_check,sync,all_squash,anonuid=999,anongid=998) user@gitlab-runner:~$ cat /etc/fstab | grep tests
IP_kube-master:/mnt/tests /mnt/tests nfs4 _netdev,auto 0 0

Никто не запрещает и сделать NFS-шару прямо на gitlab-runner’е, после чего монтировать её в pod’ы.

Примечание

Возможно, вы спросите, зачем вообще все усложнять созданием Job'а, если можно просто запустить скрипт с тестами прямо на shell-раннере? Ответ достаточно тривиален…

Мы делаем тестирование унифицированным — при таком подходе включать подобные дополнительные сущности становится легко. Некоторые тесты требуют обращения к инфраструктуре (MongoDB, RabbitMQ, PostgreSQL и т.п.) для проверки корректности работы с ними. Вдобавок к этому, мы получаем стандартный подход в деплое (пусть даже и с использованием NFS, дополнительным монтированием каталогов).

Результат

Что мы увидим, когда применим подготовленную конфигурацию?

В merge request’е будет показана сводная статистика по тестам, запущенным в его последнем пайплайне:

На каждую ошибку здесь можно нажать, чтобы получить подробности:

NET… Не удивляйтесь: просто в рамках подготовки статьи не нашлось ошибок в тестировании первого приложения, зато нашли их в другом. NB: Внимательный читатель заметит, что мы тестируем NodeJS-приложение, а на скриншотах — .

Заключение

Как видно, ничего сложного!

А в документации GitLab CI вы найдете примеры для Ruby, Go, Gradle, Maven и некоторых других. В принципе, если у вас уже есть shell-сборщик и он работает, а Kubernetes вам не нужен — прикрутить к нему тестирование будет еще более простой задачей, чем описанная здесь.

P.S.

Читайте также в нашем блоге:

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть