Dzisiaj natknąłem się na fantastyczny pomysł, który jakiś czas temu został wdrożony jako Proof of Concept w Gitlab: CI Workflows! Jestem bardzo podekscytowany i mam nadzieję, że wkrótce zostanie wdrożony 😁
Koncepcja
Obecnie zadania CI mogą być włączane do pipeline‘ów, a reguły mogą być stosowane w celu określenia, kiedy to zrobić (np. tylko wtedy, gdy konkretne pliki zostały zmodyfikowane). Pipeline może zostać wyzwolony przez wiele różnych zdarzeń: wysłanie commitów do repozytorium, stworzenie merge requestu, poprzez API lub ręcznie za pomocą interfejsu użytkownika. Już teraz jest to elastyczne i niesamowite, ale głównie w kontekście automatyzacji zadań na podstawie zawartości projektów (budowanie aplikacji, testowanie, wydawanie, wdrażanie), niekoniecznie automatyzacji w ogóle.
Pomysł Gitlab CI Workflows jest dość prosty, ale jednocześnie genialny — niech zadania CI mogą być wyzwalane przez zdarzenia systemowe. W ten sposób możliwości stają się niemal nieskończone, ograniczone jedynie wspieranymi przez system zdarzeniami oraz wyobraźnią ludzi 😉. Na przykład: chcesz wstępnie przetworzyć nowe zgłoszenie problemu? Uruchom pipeline w momencie stworzenia nowego issue. Chcesz uruchomić pipeline w merge requeście, gdy jest on oznaczony jako gotowy (usunięta została flaga Draft)? Nie ma problemu, po prostu podłącz się do zdarzenia i wywołaj API.
Możliwe użycie
Proponowana składnia bazuje na nowej opcji on
, w tym momencie nie jest jasne czy może to być pojedyncze zdarzenie, czy zbiór zdarzeń. W każdym razie mogłoby to wyglądać tak:
image: alpine
stages:
- triage
- verify
reviewer_roulette:
stage: triage
# New option introduced, defines which event we want subscribe
on: my-workflow-1/webhooks/issues/created
script:
- echo "Draw and assign reviewers..."
- ...
verify_standards:
stage: verify
needs:
- reviewer_roulette
script:
- echo "Check title, description etc."
- echo "Check if reproducer repository link is provided"
- ...
Te 2 zadania nie są zwykłymi zadaniami zawartymi w pipeline’ach. reviewer_roulette
używa wspomnianej opcji on
, więc jest uruchamiane po utworzeniu issue, podczas gdy verify_standards
zależy od niego poprzez opcję needs
. Oba zostaną uwzględnione w pipeline dla workflow, ale nie zostaną uwzględnione w zwykłych pipeline’ach opartych na gałęziach, merge requestach itp.
PoC DEMO
Film z demonstracją tego Proof of Concept został udostępniony tutaj, początkowo jako prywatny, ale po moim pytaniu został upubliczniony 🎉 Pytanie nic nie kosztuje 😉
Podsumowanie
Nie mogę się tego doczekać! Oczywiście jest wiele pytań i wątpliwości, ale te zostaną rozwiązane w epiku. My, jako użytkownicy Gitlab, również możemy być tego częścią — ta funkcjonalność może być jeszcze lepiej zaprojektowana, gdy popracujemy nad nią wspólnie! Więc nie wahaj się i przekaż opinię, jeśli masz pomysły w zakresie CI Workflows 🙂