Próbáld ki: GitLab-CI

A múlt héten bemutatott minimál projektet most Gitlab CI alá helyeztem be, hogy megmutassam, az is igen egyszerű. Amennyiben Gitlab.com szolgáltatását használod semmilyen plusz beállításra nem lesz szükséged.

.gitlab-ci.yml

A GitLabon található projekt pontosan ugyanaz, amit legutóbb néztünk, egyetlen egy különbséggel, ez pedig a .gitlab-ci.yml fájl. Amennyiben ez a fájl létezik a projekt gyökérkönyvtárában és valid, akkor elindulnak a pipeline-ok a benne leírtak szerint.

Bár a Gitlab is kínál sablon CI fájlokat, én mégis sajátot készítettem, hogy ugyanazt csinálja, mint amit az előző bejegyzésben bemutatott CI fájl csinált. Valamint igazából olyan régóta használom a GitLab CI, hogy most is csak véletlenül vettem észre, hogy van már ilyen opció, amikor a Pipeline menüre megyek és még nincs .gitlab-ci.yml.

Nézzük meg részletesen mi is van ebben a fájlban.

Első amit észre kell vennünk, hogy itt nincs külön jobs kulcsszó, hanem minden legfelső szintű kulcs egy job neve, ami nem foglalt név és egyéb projekt szintű beállítás. Yaml fájlnál ezek azok a sorok, ami előtt nincs szóköz. Itt kettő ilyen van a build és a pages. A build végzi az alkalmazás építését és tesztelését, a pages pedig a code coverage riport publikálását. Nézzük végig először a build-et.

  1. build:
  2. stage: build

Ez az első sor mindjárt egy kis magyarázatra szolgál. A gitlab pipeline egymás utáni stage-ekre és az egyes stage-en belül egymással párhuzamosan futó job-okból áll. A stage-ek neve a stages fő kulcs segítségével adható meg. Amennyiben nem adunk meg neveket, úgy alapértelmezetten három stage lesz: build, test, deploy. Mivel nem adtunk meg stages kulcsszót, ezért most csak e három közül választhatunk. A job neve ugyan szabadon választható, tehát lehetne build-and-test is, én mégis így hagytam az egyszerűség kedvéért.

  1. image: node:$nodeversion

Ennek a beállításnak a megértéséhez picit távolabbról kell indulnunk. A Gitlab-CI Runner-je többfajta Executor-ral rendelkezik. A Runner az, ami a jobokat kiveszi a sorból és átadja a megfelelő Executor-nak. Az Executor pedig, ami a különböző lépéseket végrehajtja. Én leggyakrabban a Docker és Shell executort használom. Jelen példa is a Docker executort használja, ismerkedjünk meg vele.

A Docker executor az image-ben megadott docker image segítségével indít egy konténert, melyben bind mount segítségével elérhető lesz a projekt forrása. Mint látható a példában én a hivatalos node image-et használom annak is a megfelelő verzióját, de erről majd később ejtek egy pár szót, most legyen elég annyi, hogy az image neve valahogy így fog kinézni egy konkrét esetben: node:14

  1. script:
  2. - node --version
  3. - npm ci
  4. - npm run build --if-present
  5. - npm test

Mivel Gitlab-CI-ban, szemben a Github Actions-el sem a projekt kódjának checkoutolásával, sem a node telepítésével nem kell foglalkoznunk ezek a lépések megegyeznek a korábbiakkal.

Azért nem kell foglalkoznunk, mert a Gitlab-CI minden egyes job futtatása előtt checkoutolja automatikusan a projekt kódját, valamint a node konténerben ott van a szükséges telepített node verzió.

Észre kell vennünk azonban egy nagy különbséget. A GitHub Actions-nél található step beállításokat megvannak Gitlab-CI-ban is, de azokat nem step-ekre, hanem egy nagyobb egységre a job-okra lehet megadni. Ilyenek a teljesség igénye nélkül a matrix és artifacts beállítások.

  1. parallel:
  2. matrix:
  3. - nodeversion: [12,14,16]

A parallel beállítással vehetjük rá a Gitlab-CI-t, hogy egy adott jobot párhuzamosan több verzióban futtasson le. A matrix beállításnál lehet megadni, hogy milyen változók, milyen kombinációjával történjen meg a futtatás. Jelen esetben a nodeversion változó három értékére, melyek rendre a korábbiakban is használta 12, 14, 16 verziók.

Itt utalnék vissza az image beállításnál látható felhasználásra, mely úgy gondolom ezzel együtt már egyértelmű.

  1. artifacts:
  2. paths:
  3. - coverage/lcov-report

Az artifacts kulcsszó segítségével lehet megadni azt, hogy mely fájlok vagy könyvtárak legyenek elmentve és átadva más job-oknak, vagy elérhetővé téve a UI felületen. Itt most egyetlen egy könyvtárat, a codecoverage kimenetét tartalmazó coverage/lcov-report könyvtárat tesszük elérhetővé.

A következő a pages job

  1. pages:
  2. stage: deploy

Mint látható ez már a deploy stage-ben fog futni, vagyis a build stage-ben futó build nevű job után. Amennyiben a Gitlab Pages szolgáltatását szeretnénk használni, akkor mindenképpen pages névvel kell ellátni a jobot.

  1. dependencies:
  2. - build

Ez a függőség megjelölés szükséges ahhoz, hogy a build job artifactjai itt is elérhetőek legyenek. Ez azt jelenti, hogy azok a könyvtárak amiket artifactként jelöltünk meg ott, itt is elérhetőek lesznek.

  1. script:
  2. - mv coverage/lcov-report public
  3. artifacts:
  4. paths:
  5. - public

Erre a fájl átnevezésre és artifacts bejegyzésre azért van szükség, mert a Gitlab Pages a pages job public nevű artifactját fogja publikálni. A publikált oldal a http://istvan.palocz.gitlab.io/node-action-test/ url-en meg is nézhetitek. Sajnos - mint ahogyan valószínűleg feltűnt neked is - nem https protokollal lehet elérni ezt az oldalt. Ez azért van, mert a gitlab.com-os bejelentkezési nevem (istvan.palocz) tartalmaz egy pontot, így a *.gitlab.io-ra meglévő tanúsítvány már nem lesz valid az ssl működéséből kifolyólag. Szóval, ha még nincs gilab.com azonosítód mindenképpen pont nélkülit regisztráljál! Én így jártam.

Amennyiben kipróbáltad és elakadtál, vagy szeretnél többet megtudni a témáról keress nyugodtan.

Címkék: 

Új hozzászólás