Automatické spouštění testů během buildu v GitLabu

GitLab CI/CD je součást GitLabu vytvořená pro automatizaci různých úloh v rámci vývojového procesu (jako jsou Continuous Integration (CI), Continuous Delivery (CD) a Continuous Deployment) bez nutnosti používat nástroje třetích stran. Aby vše fungovalo tak, jak má, je třeba v rámci GitLab CI/CD definovat:

• Co by se mělo stát,
• kde by se to mělo stát,
• za jakých podmínek by se to mělo spustit.

Základními stavebnímy kameny GitLab CI/CD jsou pipeline a runner. Pipeline je soubor úloh (jobs), které vykonávají jednotlivé části procesu CI/CD, a je uložena v YAML souboru .gitlab-ci.yml v kořenové složce projektu. Naprosto typickým využitím pipeline je build projektu (kompilace zdrojových souborů) a následné spuštení testů. V tomto článku si pro ukázku vytvoříme jednoduchou pipeline, která bude mít pouze jeden job.

Runner je klientská aplikace, která pro GitLab CI/CD zpřístupňuje nějaký fyzický/virtuální počítač. Lepší je však představit si runner rovnou jako počítač, na kterém pipeline poběží buď přímo v operačním systému, nebo v Dockeru (je-li na počítači nainstalován). Runner se dá sdílet mezi jednotlivými projekty (shared runner), nebo může být přidělený pouze pro specifický projekt (project runner). Toto je při použití gitlab.com velká výhoda, protože v bezplatné verzi účtu je možné bez dalších nákladů využít 400 minut sdílených runnerů pro Vaše projekty (viz https://about.gitlab.com/pricing/).

Teorii máme za sebou, tak do praxe.

V našem případě budeme pouštět jednoduchý test napsaný v Pythonu. Pro běh tohoto testu budeme tedy potřebovat runner, kde je nainstalovaný Python v požadované verzi. Pro jednoduchost využijeme sdíleného runneru z GitLabu a budeme na něm pouštět oficiální docker container s Pythonem 3.10 postavený na Alpine Linuxu. V GitLabu, v Settings > CI/CD > Runners je seznam sdílených runnerů. Každý runner má přiřazen jeden nebo více tagů, podle kterých lze poznat, na jakém OS beží nebo k čemu se hodí. Právě pomocí tohoto tagu je pak přiřazen job nebo celá pipeline k runneru.

Teď už k samotné pipeline. Kód té naší vypadá takto:

Jak již bylo zmíněno, v naší pipeline _budeme mít pouze jeden _job. První řádek tedy označuje název jobu. Náš job obsahuje tři atributy:

• tags (dle názvu) definuje runner, na kterém job poběží.
• image je název docker image (z dockerhubu), na kterém se bude job pouštět.
• Poslední, ale nejdůležitější je samotná akce (spuštění testu), reprezentovaná atributem script.

Docker container s Pythonem neobsahuje nic navíc, proto je nutné si prostředí pro běh testu nejdříve nachystat – tedy nainstalovat git (řádky 6, 7), vytvořit a aktivovat virtuální prostředí (řádky 8, 9) a doinstalovat do něj vše pro běh testu (řádek 10); a teprve pak test spustit (řádek 11).

Defaultní trigger pro spuštění akce je commit (resp. push). Při každém commitu do GitLabu tak nyní dojde ke spuštění pipeline. Pokud navíc pipeline neprojde, tak na e-mail spojený s naším účtem v GitLabu přijde notifikace.

Průběh pipeline je možné sledovat v menu GitLabu pod CI/CD > Pipelines, případně CI/CD > Jobs.