Jedna od najpotrebnijih karakteristika koja nije u besplatnoj verziji GitLaba je mogućnost glasanja protiv nuliranja spremišta za kontrolu zahtjeva za spajanjem (MR) koristeći obavezni pregled koda.
Mi ćemo sami obaviti minimalnu funkcionalnost - onemogućit ćemo Merge sve dok nekoliko programera ne pokaže "palac gore" MR-u.
Zašto je to uopće?
Naša organizacija može sebi priuštiti kupovinu GitLab licence. Ali, budući da se razvoj odvija u zatvorenom krugu bez pristupa Internetu, a postoji i strogo planiranje budžeta, kupovina samoupravnih licenci sa potrebnom funkcionalnošću može potrajati mnogo mjeseci, a vi morate raditi sada.
Kao rezultat, morate:
- ili potpuno zabraniti spajanje u zaštićene grane za neke programere, ali tada programeri koji imaju pravo na spajanje dobijaju konflikte prilikom spajanja tuđih MR-ova kao bonus;
- ili vam dozvoliti da radite nekontrolisano spajanje sa vašom glavnom granom bez pregleda koda, čak i ako je to Junior koji se tek jučer nastanio.
Prvo što sam uradio je da sam proguglao, verujući da je neko već uradio nešto slično (bez dorade koda), ali se ispostavilo da takve implementacije još nema u verziji zajednice.
Opća shema rada
Kao primjer, postavimo odobrenja zahtjeva za spajanje na testno spremište :
- Kreirajmo token za pristup GitLab API-ju (preko njega ćemo dobiti informacije o broju glasova za i protiv)
- Dodajte token u GitLab varijable
- Onemogućite spajanje ako postoje greške u procesu (ako nema dovoljno glasova "za")
- Postavite validaciju glasova kao dio CI/CD cevovoda
- Zabranit ćemo urezivanje na zaštićene grane, sve izmjene vršimo samo preko MR-a
- Hajde da proverimo šta se desilo na kraju
1. Kreirajte token za pristup API-ju
Idite na Korisničke postavke → Pristupni tokeni i zapišite token:
Račun za primanje tokena
Pristup API-ju vam omogućava da radite skoro sve sa svojim spremištima, pa predlažem da kreirate poseban Gitlab nalog, date mu minimalna prava na svoja spremišta (kao što je Reporter) i dobijete token za taj nalog.
2. Dodajte token u Gitlab varijable
Na primjer, u prethodnom koraku dobili smo token QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Otvorite Postavke → CI/CD → Varijable → Dodaj varijablu → GITLAB_TOKEN_FOR_CI
Kao rezultat, dobijamo:
Ovo se može uraditi i na jednom spremištu i na grupi spremišta.
3. Stavljamo zabranu na Merge ako nakon pregleda koda ne dobijemo odobrenje kolega
U našem slučaju, zabrana spajanja će biti da će montažni plinovod vratiti grešku ako nema dovoljno glasova.
Idite na Postavke → Općenito → Zahtjevi za spajanje → Provjere spajanja i uključite opciju Linije za montažu moraju uspješno pokrenuti.
4. Postavite cjevovod
Ako još niste napravili CI/CD cevovod za svoju aplikaciju
Kreirajte datoteku u korijenu spremišta .gitlab-ci.yml sa jednostavnim sadržajem:
stages:
- build
- test
variables:
NEED_VOTES: 1
include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"
run-myapp:
stage: build
script: echo "Hello world"
Odvojeno spremište za CI/CD konfiguraciju
Preporučio bih da napravite zasebno spremište gdje trebate kreirati myapp.gitlab-ci.yml datoteku da biste postavili cevovod. Na ovaj način možete bolje kontrolirati pristup saradnika koji mogu promijeniti cevovod za izgradnju i dobiti pristupni token.
Lokacija nove datoteke cjevovoda će se morati specificirati tako što ćete otići u myapp spremište - Postavke - CI / CD - Linije za sklapanje - Prilagođena staza CI konfiguracije - navedite novu datoteku, na primjer myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Savjet: Koristite linter da napravite promjene u GitLab CI datotekama
Čak i ako radite sami, rad preko MR-a će biti dobar pomoćnik, pokretajući sve vaše promjene u fajlovima pipelinea kroz linter. Ako napravite grešku u sintaksi YAML datoteke, to vam neće dozvoliti da prekinete radni cevovod, već će jednostavno blokirati spajanje.
Primjer kontejnera s linterima koje možete ugraditi u svoj cjevovod:
I primjer faze validacije:
stages:
- lint
lint:
stage: lint
image: sebiwi/gitlab-ci-validate:1.3.0
variables:
GITLAB_HOST: https://gitlab.com
script:
- CI_FILES=(./*.yml)
- for f in "${CI_FILES[@]}"; do
gitlab-ci-validate $f;
done;
Ostaje dodati nekoliko parametara vašem cjevovodu da bi funkcionirao:
stages:
- test
variables:
NEED_VOTES: 1
include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"
Varijabla NEED_VOTES određuje koliko "palac gore" MR mora imati da bi spajanje bilo dostupno. Vrijednost jedan znači da vi sami možete odobriti svoj MR tako što ćete ga "lajkovati".
uključuje testnu fazu, koja provjerava broj "lajkova".
Najjednostavniji cjevovod koristeći myapp.gitlab-ci.yml kao primjer
stages:
- build
- test
variables:
NEED_VOTES: 0
include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"
run-myapp:
stage: build
image: openjdk
script:
- echo CI_MERGE_REQUEST_TARGET_BRANCH_NAME $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
- java HelloWorld.java
Sadržaj check-approve.gitlab-ci.yml
ci-mr:
stage: test
script:
- echo ${CI_API_V4_URL}
- echo "CI_PROJECT_ID ${CI_PROJECT_ID}"
- echo "CI_COMMIT_SHA ${CI_COMMIT_SHA}"
- "export MR_ID=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .id else {} end" | grep --invert-match {})"
- "export MR_TITLE=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .title else {} end" | grep --invert-match {})"
- "export MR_WIP=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .work_in_progress else {} end" | grep --invert-match {})"
- "export MR_UPVOTES=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .upvotes else {} end" | grep --invert-match {})"
- "export MR_DOWNVOTES=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .downvotes else {} end" | grep --invert-match {})"
- MR_VOTES=$(expr ${MR_UPVOTES} - ${MR_DOWNVOTES})
- NEED_VOTES_REAL=${NEED_VOTES:-1}
- echo "MR_ID ${MR_ID} MR_TITLE ${MR_TITLE} MR_WIP ${MR_WIP} MR_UPVOTES ${MR_UPVOTES} MR_DOWNVOTES ${MR_DOWNVOTES}"
- echo "MR_VOTES ${MR_VOTES} Up vote = 1, down vote = -1, MR OK if votes >=${NEED_VOTES_REAL}"
- if [ "${MR_VOTES}" -ge "$(expr ${NEED_VOTES_REAL})" ];
then
echo "MR OK";
else
echo "MR ERROR Need more votes";
exit 1;
fi
image: laptevss/gitlab-api-util
rules:
- if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^release/.*$/'
Saznajte više o tome šta se dešava prilikom provjere:
- postavljeno je ograničenje da će provjera biti samo prilikom kreiranja MR-a u granama master ili release /*
- koristeći GitLab API, dobijte broj "sviđa mi se" i "ne sviđa mi se"
- izračunajte razliku između pozitivnih i negativnih odgovora
- ako je razlika manja od vrijednosti koju smo postavili u NEED_VOTES, tada blokiramo mogućnost spajanja
5. Onemogućite urezivanje zaštićenim granama
Određujemo grane za koje treba da izvršimo pregled koda i ukazujemo da se sa njima može raditi samo preko MR-a.
Da biste to uradili, idite na Podešavanja → Repozitorijum → Zaštićene grane:
6. Provjera
Postavite NEED_VOTES: 0
Radimo MR i stavljamo "dislike".
U zapisnicima izgradnje:
Sada stavite "like" i pokrenite ponovnu provjeru:
izvor: www.habr.com