Mam taki problemik, że chcę striggerować manualnego joba. O co chodzi - mam projekt z konfiguracją. Ktoś z zewnątrz może sobie złożyć merge request na projekcie z tą konfiguracją, ja wtedy akceptuję merge requesta, odpala się pipeline i odpala się manualna akcja. Ja wykonuje play i leci pipleine. Konfiguracja aktualizuje się na serwerze. Wszystko spoko tylko chciałbym nadać dostęp komuś poprzez drugi projekt do odpalania tych manualnych jobów. Nie chcę, żeby miał uprawnienia do pushowania zmian na projekcie z konfiguracją, dlatego jest proces akceptacji tego MR. Ale chcę, żeby on sam sobie zdecydował kiedy już taki zatwierdzony merge request i pipeline może się uruchomić - jeśli już to zaakceptowałem to dla mnie to bez znaczenia. Niestety deweloperzy git-a sami przyznali, że jest to zamierzone działanie, by osoba która nie ma uprawnień do merdżowania zmian nie mogła odpalać manualnie joba, ale dla mnie to jest pokręcone... Ja chcę mu nadać takie uprawnienia, co im do tego xdd
"This is the intended behavior of manual jobs - they can only be run on protected branches by folks who have merge rights to those branches. The workaround would be to unprotect the master branch - which has other consequences but those are intended as it is the manual that a manual job is considered a "write" action to that branch (e.g. we don't want to let just anyone decide to deploy to production and thus we protect manual jobs the same as protected branches.)"
Wpadłem więc na pomysł, żeby stworzyć drugi projekt do którego osoba z zewnątrz miałaby dostęp i stamtąd by sobie odpalała tego joba poprzez wpisanie tylko numerka joba w .gitlab-ci.yml
Chciałbym poprzez api wyzwolić tego 'play', ale pokazuje mi błąd 401 - unathorized.
_curl --request POST --header “PRIVATE-TOKEN: 0fa6” https://gitlab.***/api/v4/projects/262/jobs/93137/play_
{"message":"401 Unauthorized"} Co dziwne mogę striggerować sam pipeline i nie dostaję błędu, pipeline się odpala i czeka na akcję manualną.
curl --request POST \ --form token=0fa6\ --form ref=master \ https://gitlab.***/api/v4/projects/9/trigger/pipeline
Jakieś pomysły? Ten unathorized nawet występuje, gdy utworzyłem sobie osobny testowy projekt w którym branche nie są protected, i dalej dupa. Nie wiem z jakiego poziomu powinienem puścić tego curl'a, żeby się odpalił, albo jakie mu przekazać argumenty. User i hasło do gitlaba odpada, bo trzeba by to podać plain textem XD
@Drail: na tym wbudowanym w git-lab. Mamy stworzonego runnera który uruchamia się w kontenerze i ten kontener ma przejście i dostęp SSH do różnych serwerów. W kontenerze jest jakiś alpine. Ale w tym kontekście nie ma to chyba znaczenia - unathorized 401 mam zarówno z wewnątrz runnera jak i z serwera na którym stoi sam gitlab.
@Drail: spoko, ja też nad tym myślę, ale w pracy XD Stworzenie tego drugiego projektu to był mój taki pierwszy pomysł, może da się to jakoś inaczej obejść. Chcę to zrobić, bo w ogóle niepotrzebnie robimy takie zmiany na live w nocy (taki mamy przykaz z góry). W nocy musi to zrobić admin, a zwalidować musi to ktoś z biznesu. Tylko po co tam admin jeszcze? Niech sami to sobie puszczą
Mam taki problemik, że chcę striggerować manualnego joba. O co chodzi - mam projekt z konfiguracją. Ktoś z zewnątrz może sobie złożyć merge request na projekcie z tą konfiguracją, ja wtedy akceptuję merge requesta, odpala się pipeline i odpala się manualna akcja. Ja wykonuje play i leci pipleine. Konfiguracja aktualizuje się na serwerze. Wszystko spoko tylko chciałbym nadać dostęp komuś poprzez drugi projekt do odpalania tych manualnych jobów. Nie chcę, żeby miał uprawnienia do pushowania zmian na projekcie z konfiguracją, dlatego jest proces akceptacji tego MR. Ale chcę, żeby on sam sobie zdecydował kiedy już taki zatwierdzony merge request i pipeline może się uruchomić - jeśli już to zaakceptowałem to dla mnie to bez znaczenia. Niestety deweloperzy git-a sami przyznali, że jest to zamierzone działanie, by osoba która nie ma uprawnień do merdżowania zmian nie mogła odpalać manualnie joba, ale dla mnie to jest pokręcone... Ja chcę mu nadać takie uprawnienia, co im do tego xdd
"This is the intended behavior of manual jobs - they can only be run on protected branches by folks who have merge rights to those branches. The workaround would be to unprotect the master branch - which has other consequences but those are intended as it is the manual that a manual job is considered a "write" action to that branch (e.g. we don't want to let just anyone decide to deploy to production and thus we protect manual jobs the same as protected branches.)"
Wpadłem więc na pomysł, żeby stworzyć drugi projekt do którego osoba z zewnątrz miałaby dostęp i stamtąd by sobie odpalała tego joba poprzez wpisanie tylko numerka joba w .gitlab-ci.yml
Chciałbym poprzez api wyzwolić tego 'play', ale pokazuje mi błąd 401 - unathorized.
_curl --request POST --header “PRIVATE-TOKEN: 0fa6” https://gitlab.***/api/v4/projects/262/jobs/93137/play_
{"message":"401 Unauthorized"}Co dziwne mogę striggerować sam pipeline i nie dostaję błędu, pipeline się odpala i czeka na akcję manualną.
curl --request POST \
--form token=0fa6\
--form ref=master \
https://gitlab.***/api/v4/projects/9/trigger/pipeline
Jakieś pomysły? Ten unathorized nawet występuje, gdy utworzyłem sobie osobny testowy projekt w którym branche nie są protected, i dalej dupa. Nie wiem z jakiego poziomu powinienem puścić tego curl'a, żeby się odpalił, albo jakie mu przekazać argumenty. User i hasło do gitlaba odpada, bo trzeba by to podać plain textem XD
#devops #devops15k - o fajny tag, podoba mi się ( ͡° ͜ʖ ͡°) #sysadmin
Stworzenie tego drugiego projektu to był mój taki pierwszy pomysł, może da się to jakoś inaczej obejść. Chcę to zrobić, bo w ogóle niepotrzebnie robimy takie zmiany na live w nocy (taki mamy przykaz z góry). W nocy musi to zrobić admin, a zwalidować musi to ktoś z biznesu. Tylko po co tam admin jeszcze? Niech sami to sobie puszczą