Një nga funksionet më të nevojshme, i cili nuk është në versionin falas të GitLab, është aftësia për të votuar kundër anulimit të depove dhe për të kontrolluar kërkesën për bashkim (MR), duke përdorur rishikimin e detyrueshëm të kodit.
Le të bëjmë vetë funksionalitetin minimal - ne do ta ndalojmë Merge derisa disa zhvillues të japin MR një gisht.
Pse është edhe kjo e nevojshme?
Organizata jonë mund të përballojë lehtësisht blerjen e një licence GitLab. Por, meqenëse zhvillimi kryhet në një lak të mbyllur pa qasje në internet, dhe ka një planifikim të rreptë buxhetor, blerja e licencave të vetë-menaxhuara me funksionalitetin e nevojshëm mund të zvarritet për shumë muaj, por duhet të punohet tani.
Si rezultat ju duhet të:
- ose të ndalojë plotësisht Merge në degët e mbrojtura për disa zhvillues, por më pas zhvilluesit që kanë të drejtën e Bashkimit marrin konflikte kur bashkojnë MR-të e njerëzve të tjerë si bonus;
- ose jepni mundësinë për të bërë bashkime të pakontrolluara me degën tuaj master pa rishikim të kodit, edhe nëse është Junior, i cili u punësua vetëm dje.
Gjëja e parë që bëra ishte Google, duke besuar se dikush kishte bërë tashmë diçka të ngjashme (pa modifikuar kodin), por doli që nuk kishte ende një zbatim të tillë në versionin e komunitetit.
Skema e përgjithshme e punës
Si shembull, le të konfigurojmë miratimet e kërkesës së bashkimit në një depo testimi :
- Le të krijojmë një shenjë për qasje në GitLab API (nëpërmjet tij do të marrim informacione për numrin e votave "pro" dhe "kundër")
- Le të shtojmë shenjën në variablat GitLab
- Le të çaktivizojmë Merge në rast të gabimeve në tubacion (nëse nuk ka vota të mjaftueshme pozitive)
- Le të vendosim verifikimin e votës si pjesë e tubacionit CI/CD
- Ne ndalojmë kryerjen e zotimeve për degët e mbrojtura; të gjitha ndryshimet bëhen vetëm përmes MR
- Le të kontrollojmë se çfarë ndodhi në fund
1. Krijo një shenjë për të hyrë në API
Shkoni te Cilësimet e përdoruesit → Access Tokens dhe shkruani shenjën:
Llogaria për të marrë një shenjë
Qasja në API ju lejon të bëni pothuajse çdo gjë me depot tuaja, kështu që unë rekomandoj krijimin e një llogarie të veçantë Gitlab, duke i dhënë asaj të drejta minimale për depot tuaja (p.sh. Reporter) dhe marrjen e një token për atë llogari.
2. Shtoni shenjën në variablat Gitlab
Për shembull, në hapin e mëparshëm morëm një shenjë QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Hapni Cilësimet → CI/CD → Variablat → Shto variabël → GITLAB_TOKEN_FOR_CI
Si rezultat marrim:
Kjo mund të bëhet ose në një depo ose në një grup deposh.
3. Ne vendosim një ndalim për Merge nëse nuk merret miratimi i kolegëve pas shqyrtimit të kodit.
Në rastin tonë, ndalimi i Merge do të jetë që tubacioni i montimit të kthejë një gabim nëse nuk ka vota të mjaftueshme.
Shkoni te Cilësimet → Të përgjithshme → Kërkesat për bashkim → Kontrollet e bashkimit dhe aktivizoni opsionin Linjat e montimit duhet të përfundojnë me sukses.
4. Vendosja e tubacionit
Nëse nuk keni krijuar ende një tubacion CI/CD për aplikacionin tuaj
Krijoni një skedar në rrënjën e depove .gitlab-ci.yml me përmbajtjen më të thjeshtë:
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"
Depo e veçantë për konfigurimin CI/CD
Unë do të rekomandoja krijimin e një depoje të veçantë në të cilën duhet të krijoni një skedar myapp.gitlab-ci.yml për të konfiguruar tubacionin. Në këtë mënyrë ju mund të kontrolloni më mirë aksesin e pjesëmarrësve të cilët mund të ndryshojnë tubacionin e ndërtimit dhe të marrin një shenjë aksesi.
Vendndodhja e skedarit të ri të tubacionit do të duhet të specifikohet duke shkuar te depoja e myapp - Cilësimet - CI/CD - Linjat e montimit - Shtegu i konfigurimit të personalizuar CI - specifikoni skedarin e ri, p.sh. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Këshillë: Përdorni një linter për të bërë ndryshime në skedarët GitLab CI
Edhe nëse punoni vetëm, puna përmes MR do të jetë një ndihmë e mirë, duke kryer të gjitha ndryshimet tuaja në skedarët e tubacionit përmes një linteri. Nëse bëni një gabim në sintaksën e skedarit YAML, ai nuk do të prishë tubacionin tuaj të prodhimit, por thjesht do të bllokojë Merge.
Një shembull i kontejnerëve me litra që mund të ndërtoni në tubacionin tuaj:
Dhe një shembull i fazës së verifikimit:
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;
Mbetet të shtoni disa parametra në tubacionin tuaj për ta bërë atë të funksionojë:
stages:
- test
variables:
NEED_VOTES: 1
include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"
Ndryshorja NEED_VOTES përcakton se sa "bravo" duhet të ketë MR në mënyrë që Merge të jetë i disponueshëm. Një vlerë e barabartë me një do të thotë që ju vetë mund ta miratoni MR-në tuaj duke e "pëlqyer" atë.
përfshijnë përfshin fazën e testimit, e cila kontrollon numrin e "pëlqimeve".
Tubacioni më i thjeshtë duke përdorur shembullin e 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
Përmbajtja 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/.*$/'
Më shumë informacion rreth asaj që ndodh gjatë verifikimit:
- ekziston një kufizim që kontrolli do të bëhet vetëm kur krijohet MR në degët master ose lëshimi/*
- duke përdorur API-në e GitLab, marrim numrin e "pëlqimeve" dhe "mospëlqimeve"
- llogaritni dallimin midis përgjigjeve pozitive dhe negative
- nëse diferenca është më e vogël se vlera që kemi vendosur në NEED_VOTES, atëherë ne bllokojmë aftësinë për t'u bashkuar
5. Ndaloni detyrimet për degët e mbrojtura
Ne përcaktojmë degët për të cilat duhet të bëjmë rishikime të kodit dhe tregojmë se me to mund të punohet vetëm përmes MR.
Për ta bërë këtë, shkoni te Cilësimet → Depoja → Degët e mbrojtura:
6. Kontrollo
Cakto NEED_VOTES: 0
Ne bëjmë një MR dhe vendosim një "mospëlqim".
Në regjistrat e ndërtimit:
Tani vendosni "like" dhe filloni të kontrolloni përsëri:
Burimi: www.habr.com