Navzdory tomu, že každý velmi dobře ví, že testování vašeho softwaru je důležité a nutné, a mnozí to již dlouhou dobu dělají automaticky, v rozlehlosti Habru nebyl jediný recept na nastavení kombinace tak oblíbených produktů v tento výklenek jako (naše oblíbené) GitLab a JUnit . Pojďme vyplnit tuto mezeru!
úvodní
Nejprve mi dovolte uvést kontext:
Protože všechny naše aplikace běží na Kubernetes, zvážíme spuštění testů na příslušné infrastruktuře.
Pro montáž a nasazení používáme werf (z hlediska komponent infrastruktury to také automaticky znamená, že je zapojen Helm).
Nebudu zabíhat do detailů samotného vytváření testů: v našem případě si klient píše testy sám a my zajišťujeme pouze jejich spuštění (a přítomnost odpovídajícího reportu v žádosti o sloučení).
Jak bude vypadat obecný sled akcí?
Sestavení aplikace - popis této fáze vynecháme.
Nasaďte aplikaci do samostatného jmenného prostoru clusteru Kubernetes a začněte testovat.
Vyhledávání artefaktů a analýza sestav JUnit pomocí GitLab.
Odstranění dříve vytvořeného jmenného prostoru.
Nyní - k realizaci!
Nastavení
GitLab CI
Začněme fragmentem .gitlab-ci.yaml, která popisuje nasazení aplikace a spuštění testů. Výpis se ukázal být poměrně objemný, takže byl důkladně doplněn o komentáře:
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
Nyní v adresáři .helm/templates pojďme vytvořit YAML s Jobem - tests-job.yaml — ke spouštění testů a zdrojů Kubernetes, které potřebuje. Viz vysvětlení po uvedení:
Jaké zdroje popsané v této konfiguraci? Při nasazení vytvoříme pro projekt jedinečný jmenný prostor (to je uvedeno v .gitlab-ci.yaml - tests-${CI_COMMIT_REF_SLUG}) a rozbalte to:
Konfigurační mapa s testovacím skriptem;
Práce s popisem podu a zadanou direktivou command, který právě spouští testy;
PV a PVC, které umožňují ukládat testovací data.
Pozor na úvodní podmínku s if na začátku manifestu - podle toho musí být zabaleny další YAML soubory Helmova diagramu s aplikací zvrátit navrhnout tak, aby nedošlo k jejich nasazení během testování. to je:
{{- if ne .Values.global.run_tests "yes" }}
---
я другой ямлик
{{- end }}
Pokud však testy vyžadují určitou infrastrukturu (například Redis, RabbitMQ, Mongo, PostgreSQL...) - jejich YAML mohou být ne vypnout. Nasaďte je také do testovacího prostředí... samozřejmě je upravte, jak uznáte za vhodné.
Konečný dotek
Protože montáž a nasazení pomocí werf zatím funguje pouze na sestavení serveru (s gitlab-runner) a modul s testy je spuštěn na hlavním serveru, budete muset vytvořit adresář /mnt/tests na pána a dát to běžci, například přes NFS. Podrobný příklad s vysvětlením naleznete v Dokumentace K8s.
Nikdo nezakazuje vytvořit sdílení NFS přímo na gitlab-runner a poté jej namontovat do podů.
Poznámka
Možná se ptáte, proč vše komplikovat vytvářením úlohy, když můžete jednoduše spustit skript s testy přímo na shell runneru? Odpověď je celkem triviální...
Některé testy vyžadují přístup k infrastruktuře (MongoDB, RabbitMQ, PostgreSQL atd.), aby se ověřilo, že fungují správně. Testování je jednotné – díky tomuto přístupu je snadné zahrnout takové další entity. Kromě toho dostáváme standardně přístup k nasazení (i při použití NFS, dodatečné připojení adresářů).
Výsledek
Co uvidíme, když aplikujeme připravenou konfiguraci?
Požadavek na sloučení zobrazí souhrnné statistiky testů spuštěných v jeho nejnovějším kanálu:
Podrobnosti o každé chybě získáte kliknutím sem:
NB: Pozorný čtenář si všimne, že testujeme aplikaci NodeJS a na screenshotech - .NET... Nedivte se: při přípravě článku nebyly nalezeny žádné chyby při testování první aplikace, ale byly byly nalezeny v jiném.
Závěr
Jak vidíte, nic složitého!
V zásadě, pokud již máte sběratel shellu a funguje, ale nepotřebujete Kubernetes, připojení testování k němu bude ještě jednodušší úkol, než je popsáno zde. A dovnitř Dokumentace GitLab CI najdete příklady pro Ruby, Go, Gradle, Maven a některé další.