Co się dzieje po tym, jak GitLab pobierze kod?

Po pobraniu kodu repo przez GitLab do katalogu roboczego, rozpoczyna się wykonywanie pipeline CI/CD zdefiniowanego w pliku .gitlab-ci.yml.

1. Analiza .gitlab-ci.yml: GitLab Runner (lub GitLab, jeśli używany jest wbudowany CI) odczytuje konfigurację z .gitlab-ci.yml. Plik ten opisuje etapy (stages) i zadania (jobs) pipeline'u.
2. Inicjalizacja Runnara: Przydzielany jest dostępny GitLab Runner do wykonania pipeline'u. Runner uzyskuje informacje o repozytorium, commit, branchu i konfiguracji .gitlab-ci.yml.
3. Tworzenie środowiska wykonawczego: Runner przygotowuje środowisko do wykonania zadań. Może to być:
   • Maszyna wirtualna
   • Kontener (Docker, Kubernetes)
   • Dedykowany serwer
   • Shell
4. Wykonanie etapów (stages): Pipeline jest wykonywany kolejno według etapów zdefiniowanych w .gitlab-ci.yml. Zadania w jednym etapie mogą być wykonywane równolegle.
5. Wykonanie zadań (jobs): W obrębie każdego etapu wykonywane są skonfigurowane zadania. Zadanie obejmuje:
   • Definicję obrazu lub executor (wykonawcy), jeśli nie jest ustawione na poziomie pipeline lub sekcji variables.
   • Klonowanie repozytorium (już wykonane przez GitLab, ale Runner może wykonać git fetch lub git checkout dla potrzebnego stanu).
   • Przywracanie cache (jeśli skonfigurowane) w celu przyspieszenia kompilacji (np. ładowanie zależności).
   • Wykonywanie skryptów (script): To główna zawartość zadania, gdzie wykonywane są polecenia build, test, analiza lub deploy.
   • Wczytywanie artefaktów (jeśli skonfigurowane): Wyniki zadania (np. skompilowane binaria, raporty) są zapisywane do późniejszego użycia lub pobrania.
   • Zapisywanie cache (jeśli skonfigurowane) w celu przyspieszenia przyszłych uruchomień.
6. Raport o statusie: Runner wysyła status każdego zadania (sukces, błąd, anulowanie) z powrotem do GitLab. Użytkownik widzi postęp i wyniki na stronie pipeline.
7. Przejście do następnego etapu: Jeśli wszystkie zadania w bieżącym etapie zakończyły się sukcesem (lub ustawiono allow_failure), rozpoczyna się następny etap. Jeśli zadanie kończy się błędem i allow_failure nie jest ustawione, cały pipeline jest przerywany.
8. Zakończenie pipeline: Po wykonaniu wszystkich etapów (lub w przypadku błędu) pipeline kończy się. Wyniki i artefakty są dostępne przez interfejs webowy GitLab.

Przykład struktury .gitlab-ci.yml:

// Definiujemy etapy pipeline'u
stages:
  - build
  - test
  - deploy

// Zadanie build w etapie build
build_job:
  stage: build
  image: docker:latest // Używamy obrazu Docker
  script:
    - echo "Buduję aplikację..."
    - docker build -t myapp:$CI_COMMIT_SHORT_SHA . // Budowa obrazu Docker
  artifacts:
    paths:
      - myapp.tar // Zapisujemy artefakt build

// Zadanie test w etapie test
test_job:
  stage: test
  image: python:3.9 // Używamy obrazu Python
  script:
    - echo "Uruchamiam testy..."
    - pip install -r requirements.txt
    - pytest // Uruchamiamy testy
  needs: ["build_job"] // Zależy od pomyślnego zakończenia build_job

// Zadanie deploy w etapie deploy
deploy_job:
  stage: deploy
  image: ubuntu:latest // Używamy obrazu Ubuntu
  script:
    - echo "Deploy aplikacji..."
    - echo "Tu jest skrypt deploy..." // Skrypt deploy
  only: // Uruchamia się tylko przy commitach na master lub tagach
    - master
    - tags
  needs: ["test_job"] // Zależy od pomyślnego zakończenia test_job

Tak więc, pobranie kodu to tylko pierwszy krok, po którym następuje złożony proces automatycznego build, testowania i deployowania, oparty na konfiguracji .gitlab-ci.yml.