Незважаючи на те, що всі чудово знають, що тестувати свій софт важливо і потрібно, а багато хто давно робить це автоматично, на просторах Хабра не знайшлося жодного рецепта з налаштування зв'язки таких популярних у цій ніші продуктів, як (улюблений нами) 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
Кубернетес
Тепер у директорії .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 та деяких інших.