Co robi ten kreator
GitHub Actions workflow to plik YAML, który mówi GitHubowi, co robić, gdy coś dzieje się w repo: odpalać testy przy każdym pushu, budować obraz Dockera przy każdym tagu, wdrażać przy każdym mergu do main. Składnia jest prosta w teorii i pełna pułapek w praktyce: wcięcia mają znaczenie, klucz `on` parsuje się jako boolean `true` w YAML 1.1, macierze używają nawiasów kwadratowych, `needs` przyjmuje string lub listę. Jedna brakująca spacja i workflow nie ruszy.
Ten kreator pisze ten plik za Ciebie. Wybierz preset (Node CI, Docker build i push, Vercel deploy, pytest macierz, statyczna strona na Pages), edytuj triggery i joby w prostych formularzach, a prawa kolumna pokaże dokładny YAML gotowy do wrzucenia do `.github/workflows/ci.yml`. Każda opcja ma podpowiedź zwykłym językiem, a walidator wskaże brakujące nazwy, puste triggery i złe referencje między jobami.
Wszystko działa w przeglądarce. Nic się nigdzie nie wysyła, nie potrzebujesz konta, żaden workflow tu nie startuje. Wynikiem jest ten sam tekst, który napisałbyś ręcznie, tylko bez literówek.
Jak używać
- Wybierz preset u góry: Node.js CI, Docker build i push, Vercel deploy, pytest macierz, statyczna strona na Pages. Formularz wypełni sensowne wartości.
- Ustaw nazwę workflow (pokaże się w zakładce Actions) i opcjonalnie permissions w formacie `KLUCZ=wartość`.
- Włącz triggery: push (z listą gałęzi), pull_request (z listą gałęzi), schedule (wyrażenie cron), workflow_dispatch (ręczny start z UI).
- Dodaj joby w zakładkach. Dla każdego: unikalny id (używany w `needs:` i w URL), display name, runner, opcjonalnie needs i zmienne na poziomie joba.
- Włącz matrycę, jeśli chcesz testować na kilku wersjach Node, OS, czy dowolnej osi. Dodaj wiersze `klucz=wartość1, wartość2, ...`.
- Dodaj kroki w kolejności. Każdy krok to albo skrypt powłoki (`run:`), albo reużyta akcja (`uses:`). Najpopularniejsze akcje są na kliknięcie: checkout, setup-node, cache, upload-artifact, docker buildx.
- Kliknij Kopiuj w panelu podglądu albo Pobierz, żeby zapisać jako `ci.yml`. Potem zacommituj do `.github/workflows/ci.yml` w repo. GitHub wyłapie plik automatycznie, a kolejny push odpali workflow.
Kiedy się przydaje
Siedem konkretnych sytuacji, w których kreator GitHub Actions oszczędza realnie czas:
- Pierwszy workflow w nowym repo. Otwierasz kreator, klikasz „Node.js CI", zmieniasz komendę testów, kopiujesz, commitujesz. Gotowe w dwie minuty zamiast szukania właściwej składni w dokumentacji.
- Testy macierzowe na kilku wersjach Node lub Python. Składnia macierzy jest upierdliwa (`fail-fast`, nawiasy, listy). Kreator pisze to poprawnie, a podgląd pokazuje dokładnie, co wystartuje.
- Docker build i push do GHCR albo Docker Hub. Oficjalny `docker/build-push-action` chce kilku kluczy `with:` w określonej kolejności. Wybierasz preset, zmieniasz tag, wysyłasz.
- Deploy strony Next.js / Vite / Astro na Vercel albo GitHub Pages. Oba flow mają znaną sekwencję: checkout, install, build, deploy. Kreator zapisuje sekwencję, a Ty tylko wpisujesz nazwy sekretów.
- Zadania w harmonogramie: nocne backupy, tygodniowe sprzątania, miesięczne raporty. Włączasz `schedule:`, wklejasz wyrażenie cron, reszta jak każdy inny job.
- Ręcznie uruchamiane workflows (`workflow_dispatch`). Jeden przełącznik i workflow pojawia się pod przyciskiem „Run workflow" w zakładce Actions.
- Pipeline z kilkoma jobami i zależnościami: build potem deploy, build potem testy potem deploy. Chipy w polu `needs:` pokazują kolejność wprost.