GitLab CI

Wbudowane w GitLab narzędzie CI/CD, które automatycznie buduje i testuje kod po każdym commicie. Potoki definiuje się w pliku konfiguracyjnym repozytorium.

GitLab CI/CD to wbudowany w GitLaba silnik continuous integration i continuous delivery, który automatycznie buduje, testuje i wdraża Twój kod po każdym pushu. Nie musisz instalować osobnego serwera ani sklejać kilku usług — wystarczy, że w korzeniu repozytorium położysz plik .gitlab-ci.yml, a GitLab od tego momentu sam reaguje na zmiany. Pchasz commit, a w zakładce Pipelines od razu widzisz, czy nic się nie wywaliło.

Jak to działa

Konfigurację opisujesz deklaratywnie w YAML-u. Definiujesz jobs (pojedyncze zadania, np. „uruchom testy”), grupujesz je w stages (etapy, np. build, test, deploy), a całość tworzy pipeline. Joby w tym samym etapie lecą równolegle, a kolejny etap startuje dopiero, gdy poprzedni przejdzie na zielono. Jeśli testy padną, pipeline się zatrzymuje i deploy nigdy nie ruszy — o to właśnie chodzi.

Samą robotę wykonują GitLab Runners — to oddzielne procesy (najczęściej w kontenerach Dockera), które pobierają job, odpalają zdefiniowane komendy w czystym środowisku i raportują wynik. Możesz korzystać z runnerów współdzielonych przez GitLaba albo postawić własne na swoim serwerze, gdy potrzebujesz konkretnego sprzętu lub dostępu do sieci wewnętrznej.

Przykład z praktyki

Masz aplikację w Node.js i chcesz, żeby przy każdym pushu odpaliły się testy. Minimalny .gitlab-ci.yml wygląda tak:

  • stages: — lista etapów, np. - test
  • test-job: z polem stage: test
  • image: node:20 — obraz Dockera, w którym job się wykona
  • script: z komendami npm ci i npm test

Po commicie GitLab podstawia runner, ten ściąga obraz node:20, instaluje zależności, odpala testy i pokazuje status. Zielono — można mergować. Czerwono — wiesz to, zanim koleżanka z zespołu zdąży się zdenerwować.

Częste błędy i mity

Mit: pipeline zadziała bez runnera. Nie zadziała. Bez aktywnego runnera job utknie w stanie pending i będzie wisiał w nieskończoność. Wcięcia w YAML-u to nie kosmetyka — spacje zamiast tabów i jedna źle wcięta linia potrafią rozłożyć całą konfigurację. Częsty błąd początkujących to też wpisywanie sekretów (tokenów, haseł) wprost do pliku zamiast do CI/CD variables w ustawieniach projektu — pamiętaj, że .gitlab-ci.yml siedzi w repo i widzi go każdy z dostępem. I jeszcze jedno: każdy job startuje w świeżym środowisku, więc jeśli nie skonfigurujesz cache lub artifacts, kolejny etap nie zobaczy plików z poprzedniego.

Pojęcia powiązane

CI/CD, GitLab Runner, pipeline, YAML, Docker, GitHub Actions (odpowiednik z GitHuba), Jenkins, DevOps, artifacts, environment variables.