Jedna od najpotrebnijih značajki koje nema u besplatnoj verziji GitLaba je mogućnost glasanja protiv nuliranja repozitorija za kontrolu zahtjeva za spajanje (MR) pomoću obveznog pregleda koda.
Sami ćemo napraviti minimalnu funkcionalnost - onemogućit ćemo spajanje sve dok nekoliko programera ne da "palac gore" MR-u.
Zašto je to uopće?
Naša organizacija može si priuštiti kupnju GitLab licence. No, budući da se razvoj odvija u zatvorenoj petlji bez pristupa internetu i postoji strogo planiranje proračuna, kupnja licenci za samostalno upravljanje s potrebnom funkcionalnošću može potrajati nekoliko mjeseci, a vi morate raditi sada.
Kao rezultat toga, morate:
- ili potpuno zabraniti Merge u zaštićene grane za neke programere, ali onda programeri koji imaju pravo na Merge dobivaju konflikte pri spajanju tuđih MR-ova kao bonus;
- ili vam dopustiti da radite nekontrolirana spajanja sa svojom glavnom granom bez pregleda koda, čak i ako se radi o Junioru koji se tek jučer smjestio.
Prvo što sam napravio je da sam proguglao, vjerujući da je netko već napravio nešto slično (bez dorade koda), ali se pokazalo da takve implementacije još nema u community verziji.
Opća shema rada
Kao primjer, postavimo odobrenja zahtjeva za spajanje na testnom repozitoriju :
- Kreirajmo token za pristup GitLab API-ju (preko njega ćemo dobiti informaciju o broju glasova za i protiv)
- Dodajte token GitLab varijablama
- Onemogući spajanje ako postoje pogreške u procesu (ako nema dovoljno glasova "za")
- Postavite provjeru valjanosti glasova kao dio CI/CD cjevovoda
- Zabranit ćemo preuzimanje obveza na zaštićene grane, sve promjene vršimo samo putem MR-a
- Provjerimo što se na kraju dogodilo
1. Stvorite token za pristup API-ju
Idite na Korisničke postavke → Pristup tokenima i zapišite token:
Račun za primanje tokena
Pristup API-ju omogućuje vam da radite gotovo sve sa svojim spremištima, stoga predlažem da stvorite zasebni Gitlab račun, date mu minimalna prava na svoja spremišta (kao što je Reporter) i dobijete token za taj račun.
2. Dodajte token Gitlab varijablama
Na primjer, u prethodnom koraku dobili smo token QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Otvorite Postavke → CI/CD → Varijable → Dodaj varijablu → GITLAB_TOKEN_FOR_CI
Kao rezultat toga dobivamo:
To se može učiniti i na jednom repozitoriju i na grupi repozitorija.
3. Zabranjujemo Merge ako nakon pregleda koda ne dobijemo odobrenje kolega
U našem slučaju, zabrana spajanja bit će da će skupni cjevovod vratiti pogrešku ako nema dovoljno glasova.
Idite na Postavke → Općenito → Zahtjevi za spajanje → Provjere spajanja i omogućite opciju Montažne linije moraju uspješno raditi.
4. Postavite cjevovod
Ako još niste napravili CI/CD cjevovod za svoju aplikaciju
Napravite datoteku u korijenu repozitorija .gitlab-ci.yml s 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 izradu zasebnog repozitorija u kojem trebate stvoriti datoteku myapp.gitlab-ci.yml za postavljanje cjevovoda. Na ovaj način možete bolje kontrolirati pristup suradnika koji mogu promijeniti cjevovod izgradnje i dobiti pristupni token.
Lokacija nove datoteke cjevovoda morat će se navesti odlaskom na myapp repozitorij - Postavke - CI / CD - Montažne linije - Prilagođena CI konfiguracijska staza - odredite novu datoteku, na primjer myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Savjet: Koristite linter za izmjene u GitLab CI datotekama
Čak i ako radite sami, rad kroz MR bit će vam dobar pomoćnik, provodeći sve svoje promjene u datotekama cjevovoda kroz linter. Ako pogriješite u sintaksi YAML datoteke, to vam neće dopustiti da prekinete radni cjevovod, već će jednostavno blokirati Spajanje.
Primjer spremnika 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;
Preostaje dodati nekoliko parametara vašem cjevovodu kako 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 sami možete odobriti svoj MR tako što ćete ga "lajkati".
include 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 što se događa prilikom provjere:
- postavljeno je ograničenje da će provjera biti samo kod kreiranja MR-a u master ili release /* granama
- koristeći GitLab API, dohvatite 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 predaje zaštićenim granama
Određujemo grane za koje trebamo provesti pregled koda i ukazujemo da se s njima može raditi samo putem MR-a.
Da biste to učinili, idite na Postavke → Repozitorij → Zaštićene grane:
6. Provjeravanje
Postavite NEED_VOTES: 0
Radimo MR i stavljamo "dislike".
U zapisnicima izgradnje:
Sada stavite "like" i pokrenite ponovnu provjeru:
Izvor: www.habr.com