Jak wykluczyć webhook na usunięcie brancha?

Witajcie,

Mam zintegrowaną GITEA poprzez webhooka z JENKINSEM. Sęk w tym, że przy scalaniu PR w gitea jest tam taka automatyczna opcja usuwania brancha, który poprzez PR jest scalany mastera.

Dla przykładu mamy origin/master wychodzimy branchem -> feature/#123_zmiana.
Master jest w chroniony przed commitami i można dograć zmiany tylko poprzez PR (i CR) zatem chcąc zmiany z feature/#123_zmiana wgrać na master (aby uniknąć konfliktów itp) wychodzimy świeżym branchem z mastera i nazywamy go releaseMaster/#123_zmiana.
Następnie domergowujemy feature/#123_zmiana do releaseMaster/#123_zmiana
W gitea robimy PR z releaseMaster/#123_zmiana do master.

W tym momencie gitea wysyła webhooka do jenkinsa (REST JSON) aby ten zweryfikował poprawność kodu. W przypadku powodzenia odkłada w gitea komentarz, w przypadku błędu wrzuca link do konsoli jenkinsowej z błędem jako komentarz w gitea.

Do tego momentu wszystko działa dobrze.

Problem zaczyna się gdy PR przejdzie CR i chcemy go scalić do master. Ponieważ opcja "Usuń branch" jest domyślnie zaznaczona gitea po scaleniu wysyła webhooka, jenkins to przetwarza już na gałęzi master i odkłada komentarz. Natomiast zaraz po wysłaniu tego webhooka gitea usuwa branch releaseMaster/#123_zmiana (z remote) i wysyła drugiego webhooka do jenkinsa. Ten próbuje zrobić

git checkout releaseMaster/#123_zmiana

i dostaję błąd.

W gitea odnośnie eventów na webhook mam tylko takie opcje:

a tak naprawdę po scaleniu PR nie potrzebuję już wysyłać żadnego webhooka. Ktoś ma pomysł jak to zrobić?

woolfik napisał(a):

Dla przykładu mamy origin/master wychodzimy branchem -> feature/#123_zmiana.
Master jest w chroniony przed commitami i można dograć zmiany tylko poprzez PR (i CR) zatem chcąc zmiany z feature/#123_zmiana wgrać na master (aby uniknąć konfliktów itp) wychodzimy świeżym branchem z mastera i nazywamy go releaseMaster/#123_zmiana.
Następnie domergowujemy feature/#123_zmiana do releaseMaster/#123_zmiana
W gitea robimy PR z releaseMaster/#123_zmiana do master.

To nie ma sensu :|

Po prostu zintegruj master ze swoim branchem (rebase albo merge).

Jedyny sens jaki widzę ku temu, to jakbyś miał rozjechane różne branche (jakieś master, uat, develop), i rozwiązania konfliktów będą inne, ale to też jest słabe.

Riddle napisał(a):

woolfik napisał(a):

Dla przykładu mamy origin/master wychodzimy branchem -> feature/#123_zmiana.
Master jest w chroniony przed commitami i można dograć zmiany tylko poprzez PR (i CR) zatem chcąc zmiany z feature/#123_zmiana wgrać na master (aby uniknąć konfliktów itp) wychodzimy świeżym branchem z mastera i nazywamy go releaseMaster/#123_zmiana.
Następnie domergowujemy feature/#123_zmiana do releaseMaster/#123_zmiana
W gitea robimy PR z releaseMaster/#123_zmiana do master.

To nie ma sensu :|

zgadzam się

Po prostu zintegruj master ze swoim branchem (rebase albo merge).

brak gitflow więc nie da rady

Jedyny sens jaki widzę ku temu, to jakbyś miał rozjechane różne branche (jakieś master, uat, develop), i rozwiązania konfliktów będą inne, ale to też jest słabe.

ano mamy rozjechane i nic z tym nie zrobię (próbowałem ale wiąże się to ze zmianą procesów biznesowych, na które biznes nie wyraził zgody). Także podsumowując nie jestem w stanie przeprocesować zmiany procesu i trzeba się było nauczyć żyć z tym co jest ... nauczyłem się i pewne procesy automatyczne udało się wprowadzić ale jednak nadal nie wszystko bangla jak powinno

woolfik napisał(a):

ano mamy rozjechane i nic z tym nie zrobię (próbowałem ale wiąże się to ze zmianą procesów biznesowych, na które biznes nie wyraził zgody). Także podsumowując nie jestem w stanie przeprocesować zmiany procesu i trzeba się było nauczyć żyć z tym co jest ... nauczyłem się i pewne procesy automatyczne udało się wprowadzić ale jednak nadal nie wszystko bangla jak powinno

To że biznes wpływa na to w jaki sposób programiści pracują z branchami to jest mega bieda. Ja bym się na to nie zgodził.

Moim zdaniem masz dużo większe problemy w pracy, niż to że Jenkins checkoutuje usunięty branch.

@woolfik: Nie możesz dać branch filter na webhooka ?

Wlasnie nie moge bo na tworzeniu releaseMaster/#nr_zmiany
Jenkins sprawdza poprawnosc zmergowanego kodu, a na scaleniu buduje juz finalna paczkę z mastera i uploaduje gotowe paczki do pobrania na serwer

No to zostaje odznaczenie "usuń branch" i ojebanie tego po stronie jenkinsa na podstawie "jakiejś" logiki :p. Albo robienie tego ręcznie :p.
Bo domyślam się, że odznaczenie "pr zsynchronizowany" to też nie to :P.

Chociaż dla mnie to i tak brzmi jak po prostu różne webhooki dla róznych branchy :p. Ale z gitea nigdy nie pracowałem :)

Tak i poki co tak zrobilem, bo ręczne usunięcie brancha nie uruchamia webhooka ale to jest obejście a nie rozwiązanie problemu

Udało się zrobić filtrując webhooki z gitea po stronie zadania na jenkinsie: