Ciele
- Naučiť sa definovať úlohy pre GitLab-CI.
- Vyskúšať si fungovanie automatických CI nástrojov.
- Naučiť sa používať artefakty v CI.
Úvod
Mnohé kontroly a opakujúce sa úlohy je možné uskutočniť automaticky. Jedným zo spôsobov ako to realizovať je využitie tzv. CI servera, ktorý môže špúšťať zadané príkazy po každom nahratí zmien do hlavného repozitára.
Postup
Krok 1
Úloha 1.1
Vytvorte fork projektu Piškvorky a naklonujte si ho na svoj počítač.
Ide o rovnaký projekt, ktorý ste používali v minulom cvičení, ale teraz do neho pridáme automatické zostavovanie a testovanie.
Úloha 1.2
Vytvorte súbor .gitlab-ci.yml v hlavnom adresári projektu a vložte do neho nasledujúci obsah a doplňte príkaz pre preklad programu:
compile:
stage: build
image: gcc:9
script:
- gcc # Doplňte úplný príkaz pre preklad programu
Zaznamenajte zmeny a odošlite ich na server pomocou git push.
Skontrolujte webovú stránku vášho projektu v GitLabe. Pri poslednom commit-e by ste mali vidieť okruhlý indikátor, ktorý signalizuje, že sa spúšťa úloha compile. Po chvíli by ste mali vidieť zelenú fajku, ktorá znamená, že úloha prebehla úspešne. Kliknite na túto úlohu a pozrite si výpis spúšťaných príkazov a ich výstup.
Krok 2
Okrem prekladu môžeme spúšťať aj kontrolu kódu alebo testy.
Úloha 2.1
Pridajte do súboru .gitlab-ci.yml ďalšiu úlohu, ktorá bude spúšťať kontrolu kódu pomocou cppcheck. Môžete použiť nasledujúci obsah:
lint:
stage: test
image: debian:stable-slim
before_script:
- apt-get update
- apt-get install -y --no-install-recommends cppcheck
script:
- cppcheck --enable=warning,performance,portability --std=c11 --error-exitcode=1 piskvorky.c
Keďže pre cppcheck neexistuje oficiálny Docker obraz, používame všeobecný obraz debian:stable-slim a inštalujeme cppcheck v rámci úlohy. Následne spúšťame kontrolu kódu. Podstatný je parameter --error-exitcode=1, ktorý zabezpečí, že ak cppcheck nájde nejaké problémy, úloha zlyhá a budete o tom informovaní.
Úloha 2.2
Zaznamenajte zmeny a odošlite ich na server pomocou git push. Sledujte, ako sa spúšťajú jednotlivé úlohy a aké sú výsledky.
Po niekoľkých minútach by ste mali dostať email informujúci vás o zlyhaní testov. Túto informáciu tiež môžete nájsť na stránke vášho projektu v GitLabe.
Úloha 2.3
Preskúmajte informácie o zlyhaní. Prezrite si výpis programu cppcheck a zistite, aké problémy našiel.
Riešenie
V našom prípade cppcheck odhalil nesprávne ošetrenú spodnú hranicu poľa field v funkcii addSymbol(). To spôsobí zlyhanie programu ak hráč zadá pozíciu 0.
Úloha 2.4
Opravte chybu a znovu nahrajte zmeny na server. Sledujte ako budete informovaní o výsledku.
Krok 3
Niekedy je užitočné uchovávať výstupy z jednotlivých úloh, napríklad pre ďalšie analýzy alebo pre zdieľanie s ostatnými členmi tímu. V GitLabe môžeme využívať tzv. artefakty, ktoré nám umožňujú uchovávať a sprístupňovať súbory vygenerované počas úlohy. Tieto artefakty je tiež možné používať v úlohách v následných fázach pipeline.
Úloha 3.1
Upravte úlohu compile tak, aby vygenerovaný spustiteľný súbor piskvorky uložila ako artefakt. Môžete to dosiahnuť pridaním nasledujúcich riadkov do definície úlohy:
artifacts:
paths:
- piskvorky
expire_in: 1 hour
Teraz tento artefakt bude k dispozícii pre úlohy v následných fázach, ako je napríklad fáza test, kde ho môžeme použiť na spúšťanie testov.
Úloha 3.2
Pridajte úlohu smoke-test do súboru .gitlab-ci.yml, ktorá bude spúšťať jednoduchý test funkčnosti programu pomocou porovnania výstupu s očakávaným výsledkom. Rovnako ako v predchádzajúcom kroku, použite obraz debian:stable-slim a úlohú spustite v fáze test. Skript však bude odlišný:
script:
- printf '3\n1\n2\n3\n' | ./piskvorky > actual.txt
- diff -u expected.txt actual.txt
Poznámka
Operátor | za príkazom printf zabezpečuje, že výstup z printf bude poslaný ako vstup do programu piskvorky. Operátor > zas presmeruje výstup z programu piskvorky do súboru actual.txt. Následne príkaz diff porovná obsah súboru expected.txt s obsahom actual.txt. Ak sa tieto súbory líšia, úloha zlyhá a budete informovaní o rozdieloch.
Úloha 3.3
Vytvorte súbor expected.txt, ktorého obsah vygenerujte spustením programu piskvorky s rovnakým vstupom, aký používate v teste a presmerovaním výstupu do súboru expected.txt:
$ ./piskvorky > expected.txt
3
1
2
3
Zaznamenajte zmeny v do repozitára, vrátanie pridania súboru expected.txt a odošlite ich na server pomocou git push. Sledujte, ako sa spúšťajú jednotlivé úlohy a aké sú výsledky.
Poznámka
V tomto prípade vstup pre program zadávame ručne v termináli. Jeho výpisy však nevidíme, pretože výstup programu je presmerovaný do súboru expected.txt.
Tento súbor následne použijeme v úlohe smoke-test na porovnanie s výstupom z programu piskvorky. Takýto test nám pomôže overiť, či sa v budúcnosti nezaviedla nejaká chyba, ktorá by spôsobila zmenu v správaní programu.
Poznámka
Názov „smoke test“ pochádza z oblasti hardvéru, kde sa tento termín používal pre jednoduché testy, ktoré mali odhaliť zjavné problémy. V softvérovom vývoji sa tento termín používa pre základné testy, ktoré overujú, že základná funkcionalita programu funguje správne. Cieľom smoke testu nie je detailné testovanie všetkých aspektov programu, ale skôr rýchla kontrola, že program funguje aspoň v základných situáciách.
Krok 4
Na záver pridáme úlohu, ktorá pripraví balíček s naším programom a všetkými potrebnými súbormi, ktorý bude možné stiahnuť z GitLabu.
Úloha 4.1
Vytvorenie balíčka budeme robiť v ďalšej fáze, ktorú nazveme package. Keďže ta nie je v štandardnej konfigurácií GitLabu, pridajte vlastnú definíciu fáz na začiatok súboru .gitlab-ci.yml:
stages:
- build
- test
- package
Úloha 4.2
Pridajte úlohu package, ktorá bude spúšťať v fáze package a bude používať obraz debian:stable-slim. Skript tejto úlohy bude vytvárať archív piskvorky.tar.gz, ktorý bude obsahovat spustiteľný súbor piskvorky a súbor README.md. Tento archív bude uložený ako artefakt, ktorý bude možné stiahnuť z GitLabu. Na vytvorenie archívu použite príkaz tar:
tar -czf piskvorky.tar.gz piskvorky README.md