Integracja z GitLabem

Recenzent, a nie wspólny kanał

Wbudowana integracja GitLaba z Telegramem pisze na wspólny kanał, więc merge request czeka, aż ktoś przypadkiem zajrzy. WardenPoint czyta ten sam webhook i trafia do osoby, którą merge request wskazał z imienia.

Zacznij za darmo Zobacz przykłady API
Konfiguracja
Webhook projektu
Uwierzytelnienie
X-Gitlab-Token
Trafia do
Konkretnej osoby

Z czego składa się takie powiadomienie

LIVE
GitLab → webhook
MR !42 · recenzent @sjones · nowe commity
WardenPoint
odczytaj recenzentów · dopasuj login · zawiadom tę osobę
Telegram
Voice call
Email

Konfiguracja

Trzy kroki w GitLabie

Jeden webhook na projekt, a w planie Premium także na grupę. Sekret wpisujesz w pole «Secret token», a GitLab przysyła go w nagłówku X-Gitlab-Token.

  1. 1Krok 1

    Dodaj webhooka

    W projekcie wejdź w Settings → Webhooks → Add new webhook i wklej adres punktu końcowego WardenPoint w pole URL.

    $ Settings › Webhooks › Add new webhook
  2. 2Krok 2

    Wpisz sekret

    Sekret integracji wpisz w «Secret token». GitLab dołącza go do każdej dostawy jako X-Gitlab-Token; bez niego WardenPoint odrzuca żądanie.

    $ Secret token
  3. 3Krok 3

    Zaznacz zdarzenia merge requestów

    W sekcji Trigger zaznacz «Merge request events» i zapisz. Nic więcej nie trzeba — zdarzenia pipeline'ów, pushów i komentarzy są pomijane. Jeśli sprawdzasz to przyciskiem Test w GitLabie, wybierz tam również «Merge request events» — test innego rodzaju zostaje pominięty tak samo, a projekt musi mieć co najmniej jedno merge request, żeby było co wysłać.

    $ Trigger › Merge request events

Format

Webhook merge requesta

GitLab wymienia recenzentów w treści. WardenPoint odczytuje powód zdarzenia — wyznaczenie, nowe commity, ponowna prośba — i zawiadamia tych, których ten powód dotyczy.

GitLab → WardenPoint
merge-request.jsonJSON
// merge request webhook (X-Gitlab-Event: Merge Request Hook)
{
"object_kind": "merge_request",
"user": { "id": 1, "username": "root" },
"project": { "id": 15, "path_with_namespace": "acme/api" },
"object_attributes": {
"iid": 42,
"title": "Fix login redirect",
"action": "open",
"draft": false,
"author_id": 1,
"source_branch": "fix/login",
"target_branch": "main",
"url": "https://gitlab.com/acme/api/-/merge_requests/42"
},
"reviewers": [
{ "id": 25, "username": "sjones", "state": "unreviewed", "re_requested": false }
]
}
Rozsyłanie WardenPoint
WardenPoint response202
{
"status": "queued",
"notification_uuid": "notif_8h2k7yQrxJp",
"channels_planned": [
"telegram_voice",
"voice_call",
"email"
],
"escalation_chain_id": "esc_4j2k9bMcvL"
}

Reguły kierowania

Cztery reguły, z którymi przychodzi nowa integracja

Są gotowe od pierwszego dnia. Zmień zbiór, dodaj warunek albo skasuj regułę — wygrywa pierwsza pasująca, a ostatnia wycisza całą resztę.

Wyznaczenie

Ktoś dopisał Cię do merge requesta

Otwarcie merge requesta z recenzentami, dopisanie kolejnego albo zdjęcie znacznika wersji roboczej trafia do tych samych osób: wszystkich obecnych recenzentów, bez autora i bez tego, kto właśnie wykonał tę czynność.

match
reason = assigned
→ route
wszyscy recenzenci
Commity

Autor dosłał zmiany po Twoich uwagach

Push do gałęzi źródłowej albo zastosowana sugestia zawiadamia tylko tych, którzy już zaglądali w zmiany. Kto jeszcze nie otwierał, zobaczy je przy pierwszym wejściu.

match
reason = new_commits
→ route
ci, którzy już zaglądali
Ponowna prośba

Poproszono Cię o kolejne spojrzenie

GitLab oznacza recenzenta jako poproszonego ponownie i tylko on dostaje powiadomienie. Jedno zastrzeżenie: jeśli ta sama edycja dopisuje też nowego recenzenta, zdarzenie zgłasza się jako wyznaczenie — wygrywa dopisany, a poproszonego ponownie obsługuje zbiór «Poproszeni ponownie», nie ta reguła.

match
reason = re_requested
→ route
poproszony recenzent

GitLab — pytania

Częste pytania o powiadomienia z merge requestów

Webhook podaje recenzentów po nazwie użytkownika GitLaba. Na stronie integracji raz wiążesz każdą nazwę z odbiorcą; loginy pojawiają się tam same, z przychodzących zdarzeń, więc nie musisz nic przygotowywać z góry. Gdy żadna ze wskazanych osób nie jest powiązana, merge request trafia do skrzynki z wypisanymi brakującymi loginami. Gdy część jest powiązana, powiadomienie idzie do nich, a reszta czeka na powiązanie na stronie integracji.
Plan bezpłatny

Podłącz jeden projekt i otwórz merge request

Dodaj webhooka, wpisz siebie jako recenzenta i zobacz, jak przychodzi wiadomość. Bez karty, bez ryzyka na produkcji.

Zacznij za darmo Wróć do integracji
  • Trafia do konkretnej osoby
  • Respektuje godziny ciszy
  • Wersje robocze i scalone milczą