Нягледзячы на тое, што ўсе выдатна ведаюць, што тэставаць свой софт важна і трэба, а шматлікія даўно робяць гэта аўтаматычна, на прасторах Хабра не знайшлося ніводнага рэцэпту па наладзе звязкі такіх папулярных у гэтай нішы прадуктаў, як (каханы намі) GitLab і JUnit . Папоўнім гэты прабел!
Уступныя
Для пачатку абазначу кантэкст:
Так як усе нашы прыкладанні працуюць у Kubernetes, будзе разгледжаны запуск тэстаў у адпаведнай інфраструктуры.
Для зборкі і дэплою мы выкарыстоўваем werf (у сэнсе інфраструктурных кампанентаў гэта таксама аўтаматычна азначае, што задзейнічаны Helm).
У дэталі непасрэднага стварэння тэстаў удавацца не буду: у нашым выпадку кліент піша тэсты сам, а мы толькі забяспечваем іх запуск (і наяўнасць адпаведнай справаздачы ў merge request'е).
Як будзе выглядаць агульная паслядоўнасць дзеянняў?
Зборка прыкладання - апісанне гэтага этапу мы апусцім.
Дэплой прыкладання ў асобны namespace кластара Kubernetes і запуск тэсціравання.
Пошук артэфактаў і парсінг JUnit-справаздачы GitLab'ам.
Выдаленне створанага раней namespace'а.
Цяпер - да рэалізацыі!
Настройка
GitLab CI
Пачнём з фрагмента .gitlab-ci.yaml, які апісвае дэплой прыкладання і запуск тэстаў. Лістынг атрымаўся даволі аб'ёмным, таму грунтоўна дапоўнены каментарамі:
variables:
# объявляем версию werf, которую собираемся использовать
WERF_VERSION: "1.0 beta"
.base_deploy: &base_deploy
script:
# создаем namespace в K8s, если его нет
- kubectl --context="${WERF_KUBE_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. Тлумачэнні гл. пасля лістынга:
Што за рэсурсы апісаны ў гэтай канфігурацыі? Пры дэплоі ствараем унікальны для праекту namespace (гэта паказана яшчэ ў .gitlab-ci.yaml - tests-${CI_COMMIT_REF_SLUG}) і ў яго выкочваем:
ConfigMap са скрыптам цеста;
Ёў з апісаннем pod'а і названай дырэктывай command, якая як раз і запускае тэсты;
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.
Ніхто не забараняе і зрабіць NFS-шару прама на gitlab-runner'е, пасля чаго мантаваць яе ў pod'ы.
Заўвага
Магчыма, вы спытаеце, навошта наогул усё ўскладняць стварэннем Job'а, калі можна проста запусціць скрыпт з тэстамі прама на shell-ранеры? Адказ дастаткова трывіяльны…
Некаторыя тэсты патрабуюць звароты да інфраструктуры (MongoDB, RabbitMQ, PostgreSQL і да т.п.) для праверкі карэктнасці працы з імі. Мы робім тэставанне ўніфікаваным - пры такім падыходзе ўключаць падобныя дадатковыя сутнасці становіцца лёгка. У дадатак да гэтага, мы атрымліваем стандартны падыход у дэплоі (хай нават і з выкарыстаннем NFS, дадатковым мантаваннем каталогаў).
Вынік
Што мы ўбачым, калі прымянім падрыхтаваную канфігурацыю?
У merge request'е будзе паказана зводная статыстыка па тэстах, запушчаным у яго апошнім пайплайне:
На кожную памылку тут можна націснуць, каб атрымаць падрабязнасці:
NB: Уважлівы чытач заўважыць, што мы тэсціруем NodeJS-дадатак, а на скрыншотах — .NET… Не здзіўляйцеся: проста ў рамках падрыхтоўкі артыкула не знайшлося памылак у тэсціраванні першага дадатку, затое знайшлі іх у іншым.
Заключэнне
Як бачна, нічога складанага!
У прынцыпе, калі ў вас ужо ёсць shell-зборшчык і ён працуе, а Kubernetes вам не патрэбен - прыкруціць да яго тэставанне будзе яшчэ прасцейшай задачай, чым апісаная тут. А ў дакументацыі GitLab CI вы знойдзеце прыклады для Ruby, Go, Gradle, Maven і некаторых іншых.