Ena najbolj potrebnih funkcij, ki je ni v brezplačni različici GitLaba, je zmožnost glasovanja proti razveljavitvi repozitorija in nadzora Merge request (MR) z uporabo obveznega pregleda kode.
Naredimo minimalno funkcionalnost sami - prepovedali bomo Merge, dokler več razvijalcev ne bo dalo MR palca gor.
Zakaj je to sploh potrebno?
Naša organizacija si zlahka privošči nakup licence GitLab. Ker pa razvoj poteka v zaprti zanki brez dostopa do interneta in obstaja strogo načrtovanje proračuna, se lahko nakup samoupravljivih licenc s potrebno funkcionalnostjo vleče več mesecev, vendar je treba delo opraviti zdaj.
Posledično morate:
- ali popolnoma prepovedati združevanje v zaščitenih vejah za nekatere razvijalce, vendar potem razvijalci, ki imajo pravico do združevanja, prejmejo konflikte pri združevanju MR-jev drugih kot bonus;
- ali dati priložnost za nenadzorovano združevanje z vašo glavno vejo brez pregleda kode, tudi če je Junior, ki je bil zaposlen ravno včeraj.
Najprej sem pobrskal po Googlu, saj sem verjel, da je že kdo nekaj podobnega naredil (brez spreminjanja kode), vendar se je izkazalo, da v community različici te implementacije še ni.
Splošna shema dela
Kot primer konfigurirajmo odobritve zahtev za spajanje v testnem repozitoriju :
- Ustvarimo žeton za dostop do API-ja GitLab (preko njega bomo prejeli podatke o številu glasov "za" in "proti")
- Dodajmo žeton spremenljivkam GitLab
- Onemogočimo spajanje v primeru napak v cevovodu (če ni dovolj glasov za)
- Vzpostavimo preverjanje glasovanja kot del cevovoda CI/CD
- Prepovedano je sprejemanje zavez v zaščitene veje, vse spremembe so narejene samo prek MR
- Preverimo, kaj se je zgodilo na koncu
1. Ustvarite žeton za dostop do API-ja
Pojdite na Uporabniške nastavitve → Žetoni za dostop in zapišite žeton:
Račun za prejem žetona
Dostop API vam omogoča, da naredite skoraj vse s svojimi repozitoriji, zato priporočam, da ustvarite ločen račun Gitlab, mu podelite minimalne pravice do vaših repozitorijev (npr. Reporter) in pridobite žeton za ta račun.
2. Dodajte žeton spremenljivkam Gitlab
Na primer, v prejšnjem koraku smo prejeli žeton QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Odprite Nastavitve → CI/CD → Spremenljivke → Dodaj spremenljivko → GITLAB_TOKEN_FOR_CI
Kot rezultat dobimo:
To je mogoče storiti v enem repozitoriju ali v skupini repozitorijev.
3. Merge smo prepovedali, če po pregledu kode ne prejmemo odobritve sodelavcev.
V našem primeru bo prepoved Merge ta, da bo montažni cevovod vrnil napako, če ni dovolj glasov.
Pojdite v Nastavitve → Splošno → Zahteve za spajanje → Preverjanja spajanja in omogočite možnost Montažne linije se morajo uspešno zaključiti.
4. Postavitev cevovoda
Če še niste ustvarili cevovoda CI/CD za svojo aplikacijo
Ustvarite datoteko v korenu repozitorija .gitlab-ci.yml z najpreprostejšo vsebino:
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"
Ločen repozitorij za konfiguracijo CI/CD
Priporočam, da ustvarite ločeno skladišče, v katerem morate ustvariti datoteko myapp.gitlab-ci.yml za konfiguracijo cevovoda. Na ta način lahko bolje nadzorujete dostop udeležencev, ki lahko spremenijo cevovod gradnje in prejmejo žeton za dostop.
Mesto nove datoteke cevovoda bo treba določiti tako, da obiščete repozitorij myapp – Nastavitve – CI/CD – Montažne linije – Pot konfiguracije CI po meri – določite novo datoteko, npr. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Namig: uporabite linter za spreminjanje datotek GitLab CI
Tudi če delate sami, vam bo delo prek MR v dobro pomoč, saj boste vse svoje spremembe datotek cevovoda izvajali prek linterja. Če naredite napako v sintaksi datoteke YAML, to ne bo prekinilo vašega proizvodnega cevovoda, ampak bo preprosto blokiralo spajanje.
Primer vsebnikov s lintri, ki jih lahko vgradite v svoj cevovod:
In primer stopnje preverjanja:
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;
Ostaja, da svojemu cevovodu dodate nekaj parametrov, da bo deloval:
stages:
- test
variables:
NEED_VOTES: 1
include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"
Spremenljivka NEED_VOTES določa, koliko "palcev gor" mora imeti MR, da je Merge na voljo. Vrednost enaka ena pomeni, da lahko sami potrdite svoj MR tako, da ga »všečkate«.
include vključuje testno stopnjo, ki preverja število "všečkov".
Najenostavnejši cevovod na primeru myapp.gitlab-ci.yml
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
Vsebina 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/.*$/'
Več informacij o tem, kaj se zgodi med preverjanjem:
- obstaja omejitev, da bo preverjanje opravljeno samo pri ustvarjanju MR v vejah master ali release/*
- z uporabo API-ja GitLab dobimo število "všečkov" in "ni mi všeč"
- izračunajte razliko med pozitivnimi in negativnimi odgovori
- če je razlika manjša od vrednosti, ki smo jo nastavili v NEED_VOTES, potem blokiramo možnost združevanja
5. Prepoved zavez v zaščitene veje
Določimo veje, za katere moramo opraviti pregled kode, in navedemo, da je z njimi mogoče delati samo prek MR.
Če želite to narediti, pojdite v Nastavitve → Repozitorij → Zaščitene veje:
6. Preverite
Nastavite NEED_VOTES: 0
Naredimo MR in postavimo "ni všeč".
V dnevnikih gradnje:
Zdaj postavite »všeč mi je« in znova začnite preverjati:
Vir: www.habr.com