Integracja z GitLabem

Integracja z GitLabem działa jak integracja z GitHubem: wpisz klucz zadania w nazwie gałęzi albo w tytule merge requesta, a zadanie pokaże stan kodu i po scaleniu może się samo ukończyć. Działa z gitlab.com i z własnymi instancjami GitLaba (self-managed). assign2me zapisuje tylko metadane, nigdy kodu.

Połącz GitLaba (Administrator)

Administrator otwiera Integracje i łączy GitLaba:

1. Podaj adres instancji. Domyślnie https://gitlab.com.
2. Wklej token dostępu grupy albo projektu z rolą co najmniej Maintainer i zakresem api.
3. assign2me sprawdza token i pokazuje grupy i projekty, do których daje dostęp.
4. Wybierz projekty. assign2me samo zakłada w nich webhooki z sekretem.

Token jest przechowywany zaszyfrowany. 14 dni przed jego wygaśnięciem osoba, która połączyła GitLaba, dostaje ostrzeżenie w aplikacji i e-mailem. Po wygaśnięciu połączenie ma stan Wymaga ponownego połączenia, dopóki nie podasz nowego tokenu.

Połączenie z GitLabem należy do dokładnie jednej organizacji assign2me.

Tryb „tylko webhooki”

Jeśli wasz GitLab działa w sieci firmowej, do której assign2me nie ma dostępu, wybierz tryb „tylko webhooki”. assign2me pokazuje adres webhooka i sekret, a webhook dodajesz w GitLabie samodzielnie. Zaznacz zdarzenia push, merge request i pipeline.

W tym trybie powiązania i stany działają na podstawie zdarzeń wysyłanych przez GitLaba. assign2me nie może zapytać GitLaba o bieżący stan, więc utracone zdarzenie naprawia dopiero kolejne zdarzenie tego samego merge requesta. Ekran Integracje mówi o tym wprost.

Przypnij projekty i używaj kluczy zadań

Właściciel projektu przypina projekty GitLaba (repozytoria) do projektu w assign2me, tak jak przy GitHubie. assign2me wiąże zadanie, gdy jego klucz, np. A2M-142, bez względu na wielkość liter pojawi się w:

• nazwie gałęzi, np. a2m-142-limit-zapytan,
• tytule albo opisie merge requesta,
• wiadomości wypchniętego commita.

Klucz poprzedzony słowem ref, refs albo related to tworzy powiązanie tylko informacyjne. Kopiuj nazwę gałęzi w zadaniu daje gotową nazwę gałęzi i polecenie git checkout -b.

Automatyzacje

Właściciel projektu może włączyć, każdą osobno, wszystkie domyślnie wyłączone:

• po otwarciu merge requesta przenieś zadanie do wybranej sekcji,
• po scaleniu ukończ zadanie albo przenieś je do wybranej sekcji.

Scalenie to połączenie z gałęzią domyślną, a także z gałęziami docelowymi dodanymi przez Właściciela (np. release/*). Zadanie jest ukończone dopiero po scaleniu ostatniego otwartego merge requesta powiązanego z nim odwołaniem zamykającym, i tylko dla zadań z tego projektu i zdarzeń z przypiętych do niego repozytoriów. Zadanie przywrócone ręcznie nie zostanie ponownie ukończone przez to samo scalenie. Każda zmiana trafia do historii zadania ze źródłem „GitLab” i numerem merge requesta.

Stan kodu w zadaniu

Sekcja Kod w zadaniu pokazuje gałęzie i merge requesty: numer, tytuł, autora, stan (szkic, otwarty, czeka na przegląd, zatwierdzony, zmiany wymagane, scalony, zamknięty bez scalenia), recenzentów i wynik pipeline’u (w toku, zaliczony, niezaliczony). Filtr Kod i karta Czeka na przegląd w podsumowaniu projektu działają jak przy GitHubie.

W trybie pełnym assign2me co 6 godzin odświeża stan otwartych powiązanych merge requestów, żeby wyłapać zdarzenia, które zginęły.

Czego nie widzi gość

Goście nie widzą sekcji Kod, a stan kodu nigdy nie trafia na kanał Slack. Informacje o kodzie widzą tylko osoby z dostępem do zadania.

Odłączenie

Po odłączeniu GitLaba assign2me usuwa założone przez siebie webhooki (jeśli instancja jest dostępna) i kasuje token. Nowe zdarzenia są odrzucane w ciągu 60 sekund, a przypięcia repozytoriów do projektów są usuwane. Istniejące powiązania zostają w zadaniach z ostatnim znanym stanem, oznaczone jako nieaktualne. Administrator może je usunąć razem z połączeniem.