Generator macierzy GitLab CI

Generator macierzy GitLab CI dla wielu wersji

Generator tworzy plik .gitlab-ci.yml z etapami build, test i opcjonalnym deployem oraz z parallel: matrix. Jeden szablon joba może dzięki temu sprawdzić projekt na kilku wersjach PHP, Node.js albo Pythona. Wartości trafiają do YAML jako cytowane łańcuchy, więc numer wersji nie zostanie przypadkowo odczytany jako liczba, wartość logiczna ani nowy element konfiguracji.

Narzędzie jest przeznaczone do przygotowania bezpiecznego punktu wyjścia. Wygenerowany potok odwołuje się do skryptów ./scripts/build.sh, ./scripts/test.sh i ./scripts/deploy.sh; przed commitem trzeba dopasować je do repozytorium. Jeśli potrzebujesz prostszego pliku bez macierzy, porównaj wynik z generatorem GitLab CI. Składnię gotowego pliku możesz dodatkowo sprawdzić w walidatorze YAML.

Jak działa parallel: matrix

Po włączeniu macierzy generator definiuje zmienną odpowiednią dla środowiska: PHP_VERSION, NODE_VERSION albo PY_VERSION. GitLab rozwija wpis na osobne wykonanie joba dla każdej wartości. Obraz kontenera korzysta z jawnej składni zmiennej, na przykład php:${PHP_VERSION}-cli, więc sufiks obrazu nie staje się częścią nazwy zmiennej. Gdy macierz jest wyłączona, generator używa pierwszej podanej wersji bez tworzenia niezdefiniowanej zmiennej.

test:
  stage: test
  image: 'php:${PHP_VERSION}-cli'
  parallel:
    matrix:
      - PHP_VERSION: ['8.2', '8.3']
  script:
    - ./scripts/test.sh

Etapy i spójność jobów

Lista stages określa kolejność wykonywania. Generator zawsze buduje joby build i test, dlatego oba etapy muszą znaleźć się na liście, a build musi poprzedzać test. Po zaznaczeniu deploy wymagany jest także etap deploy umieszczony po test. Taka kontrola zapobiega plikowi, który parsuje się poprawnie, lecz uruchamia weryfikację albo wdrożenie w złej kolejności. Nazwy etapów są ograniczone do bezpiecznych znaków i maksymalnej długości.

Cache oddzielony dla gałęzi i wersji

Wspólny cache różnych interpreterów potrafi powodować trudne do odtworzenia błędy. Klucz zawiera więc CI_COMMIT_REF_SLUG oraz wersję z macierzy. Ścieżka zależy od wybranego środowiska: vendor/ dla PHP, node_modules/ dla Node.js oraz .cache/pip/ dla Pythona. Polityka pull-push pozwala jobowi pobrać istniejący cache i zaktualizować go po pracy.

Deploy tylko z domyślnej gałęzi

Job wdrożeniowy używa rules i porównuje CI_COMMIT_BRANCH z CI_DEFAULT_BRANCH. Jest to odporniejsze niż wpisanie na sztywno nazwy main, ponieważ część repozytoriów nadal korzysta z innej gałęzi domyślnej. Samo ograniczenie gałęzi nie zastępuje protected environments, akceptacji manualnej ani ochrony sekretów. Dane dostępowe przechowuj w chronionych i maskowanych zmiennych GitLab, nigdy w YAML.

Elementy generowanego pliku

Jak przygotować konfigurację

1. Wybierz preset PHP, Node.js albo Python i pozostaw tylko rzeczywiście wspierane wersje.
2. Ustal etapy; zachowaj build i test, a deploy dodaj tylko wtedy, gdy repozytorium ma bezpieczny skrypt wdrożeniowy.
3. Zdecyduj, czy koszty uruchamiania pełnej macierzy są uzasadnione na każdej gałęzi.
4. Wygeneruj YAML, skopiuj go do katalogu głównego repozytorium i dopasuj polecenia skryptów.
5. Zweryfikuj YAML, użyj GitLab CI Lint i wykonaj potok na gałęzi testowej przed połączeniem zmian.

Najczęstsze pytania