Generator GitLab CI/CD

Name: Generator GitLab CI/CD – .gitlab-ci.yml bez pisania od zera
Availability: InStock
Author: Webp.pl

Generuj plik .gitlab-ci.yml dla Node.js, Python, PHP, Docker i innych stacków. Stages, jobs, cache, artefakty i deploy konfigurowane wizualnie. Kopiuj gotowy plik. Bezpłatnie.

Bezpieczne (SSL)

Przetwarzanie Lokalne

100% Darmowe

Przejdź do narzędzia

Instrukcja

1

Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku.
2

Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce.
3

Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.

                                                function runTool() {

                                                  return "Wynik gotowy w 0.1s";

                                                }

Ustawienia

Project type

Deploy when

Obraz

Stages

Before script

28 znaków

Variables

Install cmd

Test cmd

Build cmd

Cache Opcja narzędzia

Artifacts Opcja narzędzia

Deploy Opcja narzędzia

Deploy cmd

Deploy ref

Dane wejściowe

136 znaków

Wynik

YAML

# Wygenerowano w generatorze GitLab CI (webp.pl)
# Commit this file as .gitlab-ci.yml at the repository root

image: node:20-alpine

stages:
  - lint
  - test
  - build
  - deploy

variables:
  NODE_ENV: "test"

before_script:
  - 'node --version'
  - 'npm --version'

.default_job: &default_job
  retry: 1
  interruptible: true
  cache:
    key:
      files:
        - package-lock.json
        - yarn.lock
    paths:
      - .npm/
      - node_modules/

lint:
  <<: *default_job
  stage: lint
  script:
    - 'npm ci'
    - 'npm run lint'

test:
  <<: *default_job
  stage: test
  script:
    - 'npm ci'
    - 'npm test'

build:
  <<: *default_job
  stage: build
  script:
    - 'npm ci'
    - 'npm run build'
  artifacts:
    when: always
    expire_in: 7 days
    paths:
      - dist/
      - build/

# Notes:
# - Pipeline GitLab dla aplikacji Node.js: instalacja zależności, testy, budowanie paczki produkcyjnej i opcjonalne wdrożenie z gałęzi main.

Podsumowanie

Preset: NODE • Image: node:20-alpine • Stages: lint,test,build,deploy • Cache: on • Artifacts: on • Deploy job: not included

yaml: # Wygenerowano w generatorze GitLab CI (webp.pl) # Commit this file as .gitlab-ci.yml at the repository root image: node:20-alpine stages: - lint - test - build - deploy variables: NODE_ENV: "test" before_script: - 'node --version' - 'npm --version' .default_job: &default_job retry: 1 interruptible: true cache: key: files: - package-lock.json - yarn.lock paths: - .npm/ - node_modules/ lint: <<: *default_job stage: lint script: - 'npm ci' - 'npm run lint' test: <<: *default_job stage: test script: - 'npm ci' - 'npm test' build: <<: *default_job stage: build script: - 'npm ci' - 'npm run build' artifacts: when: always expire_in: 7 days paths: - dist/ - build/ # Notes: # - Pipeline GitLab dla aplikacji Node.js: instalacja zależności, testy, budowanie paczki produkcyjnej i opcjonalne wdrożenie z gałęzi main. summary: Preset: NODE • Image: node:20-alpine • Stages: lint,test,build,deploy • Cache: on • Artifacts: on • Deploy job: not included

Oceń to narzędzie:

Powiązane narzędzia

Inne narzędzia, które mogą Ci się przydać

Generator pliku .gitlab-ci.yml – GitLab CI/CD bez YAML z głowy

Konfiguracja pipeline CI/CD w GitLab wymaga znajomości składni YAML i specyfiki gitlab-ci.yml: stages, jobs, rules, cache, artefaktów, zmiennych i połączenia z GitLab Container Registry lub Kubernetes. Narzędzie generuje kompletny plik na podstawie wybranego stacku technologicznego.

generator gitlab-ci.yml GitLab CI/CD pipeline konfiguracja CI/CD YAML gitlab pipeline generator

Struktura .gitlab-ci.yml

Stages: kolejność etapów (build → test → deploy). Jobs: zadania w stages (mogą być równoległe). Script: komendy do wykonania. Image: Docker image dla joba. Cache: katalogi między jobami (np. node_modules). Artifacts: pliki przekazywane między stages (np. dist/). Rules/only/except: warunkowe uruchamianie.

Gotowe szablony stacków

Node.js: npm ci + test + build + Dockerfile + push do registry. Python: pip install + pytest + coverage report. PHP: composer install + phpunit + phpstan. Docker: multi-stage build + trivy security scan + push. Java/Maven: mvn test + jar + deploy. Go: go test + go build + binary artifact.

Optymalizacja pipeline

Cache node_modules (key: ${CI_COMMIT_REF_SLUG}): znacznie przyspiesza buildy. Parallel jobs: matrix strategy dla wielu wersji Node/Python. Interruptible: true: nowe push anuluje stary job tej samej gałęzi. Needs (DAG): job startuje gdy poprzednik gotowy, bez czekania na cały stage. Dind (Docker-in-Docker): budowanie obrazów w CI.

Deploy i środowiska

GitLab Environments: automatyczne tworzenie środowisk (review apps dla MR). Kubernetes: helm upgrade lub kubectl apply z kubeconfig ze zmiennych CI. SSH deploy: rsync + SSH key w CI/CD variables. GitLab Pages: artifacts:paths: [public/] + pages job – automatyczne wdrożenie statycznej strony.

Jak działa generator .gitlab-ci.yml

Generator nie zgaduje, co ma być w pipeline – działa jak mapowanie decyzji z formularza na konkretne klucze YAML. Każdy wybór (stack, menedżer pakietów, komenda instalacji, komenda testów, sposób wdrożenia) odpowiada osobnemu blokowi w pliku: stages ustala kolejność etapów, job dostaje przypisany stage, image i listę script, a warunki uruchomienia trafiają do sekcji rules.

Kolejność składania też ma znaczenie. Najpierw powstaje wspólna część pliku ze zmiennymi i ustawieniami domyślnymi, potem poszczególne joby, a na końcu sekcje globalne, takie jak stages i cache. Dzięki temu joby mogą dziedziczyć po sobie ustawienia przez extends i nie powtarzają tych samych komend w kilku miejscach.

Wynik to zwykły tekst YAML, który wklejasz do repozytorium. Generator nie łączy się z twoim GitLabem, nie tworzy runnerów i nie sprawdza, czy wskazany obraz istnieje w rejestrze. Pilnuje składni, nazw kluczy oraz spójności między etapami a jobami, żeby plik przeszedł walidację GitLab CI Lint.

Przykład: pipeline dla aplikacji Node.js z obrazem Docker i deployem przez SSH

Wybierz stack Node.js i menedżer pakietów npm. W polu instalacji wpisz npm ci, a w polu testów npm test, żeby job testowy korzystał z lockfile'a i odtwarzalnej instalacji.
Ustaw etap build: komenda npm run build, a katalog wynikowy (np. dist/) dopisz do artifacts, aby pliki przeszły do kolejnego etapu bez ponownego budowania.
Włącz cache z kluczem ${CI_COMMIT_REF_SLUG} i ścieżką node_modules – kolejne pipeline'y na tej samej gałęzi nie instalują zależności od zera.
W sekcji rules ustaw warunki: joby testowe i build dla każdego pusha oraz merge requesta, a budowę obrazu i deploy tylko dla gałęzi main.
Dodaj etap deploy: budowa obrazu z Dockerfile, logowanie do GitLab Container Registry zmiennymi CI_REGISTRY_USER i CI_REGISTRY_PASSWORD, push obrazu, a na końcu wdrożenie przez rsync i klucz SSH trzymany w CI/CD variables.
Skopiuj wynik do pliku .gitlab-ci.yml w katalogu głównym repozytorium, sprawdź go w GitLab CI Lint i uruchom pipeline. Jeśli runner nie ma dostępu do Dockera, włącz dind (docker:dind) albo użyj runnera powłokowego.

Co odpowiada za co w wygenerowanym pliku

Opcja w generatorze	Co trafia do .gitlab-ci.yml	Kiedy ma znaczenie
Stack Node.js	image z Node, npm ci, komenda testów, komenda build	projekty JavaScript i TypeScript
Cache	cache: key: ${CI_COMMIT_REF_SLUG} i lista paths	gdy instalacja zależności zajmuje większość czasu joba
Artifacts	artifacts: paths z katalogiem wyniku	gdy kolejny etap potrzebuje plików z poprzedniego
Rules	rules: if z warunkiem na gałąź lub MR	gdy deploy ma działać tylko z main, a testy zawsze
Needs	needs z listą jobów poprzedzających	gdy chcesz startować job bez czekania na cały etap
Interruptible	interruptible: true w jobie	gdy nowy push ma anulować stary job tej samej gałęzi
Dind	docker:dind jako service i zmienne DOCKER_*	gdy pipeline buduje obrazy kontenerów
Kubernetes	helm upgrade lub kubectl apply z kubeconfig ze zmiennych CI	gdy wdrażasz na klaster zamiast na pojedynczy serwer

Praktyczne wskazówki

Trzymaj komendy w jednej linii – lista script wykonuje każdą pozycję jako osobny proces powłoki, więc wieloetapowe operacje łącz przez &&, jeśli mają działać w tym samym kontekście.
Używaj needs zamiast czekania na etap – job z needs startuje, gdy jego poprzednicy są gotowi, a nie gdy zakończy się cały stage. Skraca to pipeline zwłaszcza przy wielu równoległych jobach.
Nazwij joby od zadań, nie od technologii – test, build, deploy czyta się lepiej w widoku pipeline'u niż node-job-1, a przy zmianie stacku nazwy zostają aktualne.
Nie wpisuj sekretów do pliku – klucze SSH, tokeny i kubeconfig trzymaj w CI/CD variables (z maskowaniem), a w YAML tylko się do nich odwołuj.
Zacznij od minimalnego pipeline'u – najpierw instalacja, testy i build, a dopiero potem cache, artifacts i deploy. Łatwiej znaleźć błąd w krótkim pliku niż w rozbudowanym.

Czego generator nie uwzględni

Nie zna twojego runnera – tagi runnera, typ executora, dostęp do Dockera i limit czasu joba ustawiasz w konfiguracji GitLaba, więc wygenerowany plik może wymagać dopasowania tagów.
Nie sprawdzi komend – generator pilnuje składni YAML, a nie tego, czy w projekcie istnieje skrypt npm, plik testowy albo Dockerfile. Zła nazwa komendy wyjdzie dopiero w logu pipeline'u.
Nie zweryfikuje obrazów i wersji narzędzi – tagi obrazów oraz wersje środowisk musisz dopasować do projektu; narzędzie nie sprawdza, czy dany tag istnieje w rejestrze.
Nie obejmuje zaawansowanych funkcji GitLaba – include z zewnętrznych szablonów, child pipelines, ochrona środowisk i reguły zatwierdzeń wymagają ręcznej konfiguracji i zależą od planu licencyjnego.

Najczęstsze pytania

Czym różni się GitLab CI od GitHub Actions?

GitLab CI: natywny, .gitlab-ci.yml, wbudowany Container Registry, dostępny self-hosted. GitHub Actions: .github/workflows/*.yml, marketplace akcji, darmowe dla publicznych repozytoriów. Składnia różni się ale koncepcje (stages/jobs/matrix) są podobne. GitLab ma wbudowane security scanning (DAST/SAST).

Jak przyspieszyć wolny pipeline CI?

Cache dependencies (node_modules, pip cache, composer). Parallel test splits (pytest-split, jest --shard). Interruptible: true dla gałęzi feature. Docker layer caching (--cache-from). Incremental builds. Pomijaj zbędne stages (rules: changes: [src/**/*]).

Jak bezpiecznie przechowywać sekrety w GitLab CI?

GitLab CI/CD Variables (Settings → CI/CD → Variables): Masked (nie wyświetlają się w logach) + Protected (tylko dla protected branches). Vault integration: HashiCorp Vault jako external secrets backend. Nigdy nie commituj secretów do .gitlab-ci.yml – tylko referencje: $SECRET_NAME.

Co to jest GitLab Runner i jak go uruchomić?

GitLab Runner to agent wykonujący joby. Typy executorów: Shell (host OS), Docker (izolacja), Kubernetes (cloud-native). Instalacja: curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash && sudo apt install gitlab-runner. Rejestracja: gitlab-runner register.

Jak korzystać z GitLab Container Registry?

W .gitlab-ci.yml: image: docker:dind. Login: echo $CI_REGISTRY_PASSWORD | docker login -u $CI_REGISTRY_USER $CI_REGISTRY --password-stdin. Build: docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA. Push: docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA.

Jak wygenerować plik .gitlab-ci.yml bez znajomości YAML?

Wybierz w formularzu stack, komendy instalacji, testów i build oraz sposób wdrożenia. Generator złoży z tego kompletny plik ze stages, jobami i rules, który wystarczy skopiować do repozytorium.

Gdzie w repozytorium musi leżeć plik .gitlab-ci.yml?

W katalogu głównym repozytorium i dokładnie pod tą nazwą. GitLab szuka pliku konfiguracyjnego w katalogu głównym i przy innej lokalizacji pipeline się nie uruchomi.

Czy wygenerowany plik obsługuje GitLab Container Registry?

Tak, jeśli zaznaczysz budowę i push obrazu. Job loguje się zmiennymi CI_REGISTRY_USER i CI_REGISTRY_PASSWORD, które GitLab udostępnia automatycznie w pipeline.

Dlaczego deploy uruchamia się przy każdym pushu?

Najczęściej brakuje warunku w sekcji rules, więc job startuje domyślnie dla każdej zmiany. Dodaj regułę z warunkiem na gałąź main, żeby wdrożenie działało tylko po merge'u.

Jak przyspieszyć pipeline, gdy instalacja zależności trwa długo?

Włącz cache z kluczem ${CI_COMMIT_REF_SLUG} i ścieżką katalogu zależności, np. node_modules. Kolejne uruchomienia na tej samej gałęzi korzystają wtedy z zapisanych paczek.

Czy mogę ręcznie edytować wygenerowany plik?

Tak, to zwykły tekst YAML. Generator daje punkt startowy z poprawną strukturą, a komendy, tagi i warunki możesz dopasować do swojego projektu.

Powiązane narzędzia: walidator YAML, generator Dockerfile i generator GitHub Actions.