GitLab – Pipelines między projektami

Dzisiaj na warsztat bierzemy GitLab i jego Pipelines. Od niedawna w darmowej wersji Core możemy korzystać z nich między projektami. W wersji płatnej ta funkcjonalność jest dostępną od dłuższego czasu.

Jeśli nie wiesz co to GitLab, jest to alternatywne rozwiązanie dla GitHub, lecz rozwijane jako projekt open source. Więcej informacji: https://about.gitlab.com ↗️

Jeśli nie wiesz czym są Pipelines, to w skrócie jest to rozwiązanie CI/CD które pozwala na automatyzację wielu rzeczy np. budowanie projektu, testowanie czy deployment. Więcej informacji: https://docs.gitlab.com/ee/ci/pipelines/ ↗️

Problem

Mamy projekt app, który w Pipeline wykonuje dwa Joby, build oraz deploy. Istnieje też drugi projekt, test-runner, który uruchamia Job test w Pipeline. Chcemy, by w Pipeline w projekcie app, po wykonaniu Job build, uruchomił się Pipeline z projektu tests-runner, a w nim Job tests. Jak widać, mamy tutaj zależność app => tests-runner:

  1. app – build
  2. tests-runner – tests
  3. app – deploy

Rozwiązanie

Z pomocą przychodzi nam funkcja Multi-project pipelines (https://docs.gitlab.com/ee/ci/multi_project_pipelines.html ↗️). Pozwala to na zdefiniowanie Job w projekcie app który wywoła Pipeline w projekcie tests-runner:

build:
  stage: build
  script: ./build.sh

trigger-test:
  stage: test
  trigger:
    project: ddziaduch/tests-runner
    branch: master
    strategy: depend
    
deploy:
  stage: deploy
  script: ./deploy.sh

W powyższej konfiguracji Pipeline mamy zdefiniowane trzy Joby. W tym przypadku interesuje nas drugi, o nazwie trigger-tests. Ma zadeklarowane polecenie trigger które uruchamia Pipeline w projekcie ddziaduch/test-runner na branchu master. Dodatkowo ustawiamy strategię depend, co oznacza że jeśli Pipeline w projekcie test-runner się nie powiedzie, to Pipeline w app również. Składnia jest super prosta i otrzymujemy taki rezultat:

Multi-project pipelines

Na tym widoku widzimy 3 Joby w projekcie app oraz rezultat Pipeline w projekcie test-runner. W tym przypadku akurat wszystko wykonało się poprawnie. A co jeśli Pipeline w projekcie test-runner się nie powiedzie?

Niepowodzenie Pipeline w projekcie test-runner

Zgodnie ze strategią depend, Pipeline w app również się nie powiódł. Automatycznie zostaję o tym powiadomiony, na czym mi zależało.

Co jeszcze możesz zrobić:

  • przekazać zmienne do Pipeline zależnego;
  • odzwierciedlić status z Pipeline nadrzędnego;
  • wywołać Pipeline w projekcie nadrzędnym w przypadku zmian w projekcie podrzędnym;

Więcej informacji: https://docs.gitlab.com/ee/ci/multi_project_pipelines.html ↗️

Podsumowanie

Multi-project pipelines to idealne rozwiązanie w przypadku architektury rozproszonej. Możesz w prosty sposób zbudować ciąg zależności w projektach np. zbudowanie i wdrożenie jednego mikroserwisu spowoduje zbudowanie i wdrożenie w kolejnych. Składnia jest bardzo prosta i pozwala bardzo szybko skonfigurować zależności. Mi to zajęło 10 minut 🙂