ProHoster > Blog > Administrim > Kontrolli i kodit në Gitlab CE: nëse nuk ka aprovime të Merge request, por shumë dëshiron.

Kontrolli i kodit në Gitlab CE: nëse nuk ka aprovime të Merge request, por shumë dëshiron.

Kontrolli i kodit në Gitlab CE: nëse nuk ka aprovime të Merge request, por shumë dëshiron.

Një nga funksionet më të nevojshme, që mungon në versionin falas të GitLab, është mundësia për të votuar kundër fshirjes së një depozite duke kontrolluar Merge request (MR), duke përdorur një kërkesë të detyrueshme për rishikimin e kodit.

Do ta realizojmĂ« funksionalitetin minimal vetĂ« — do tĂ« ndalojmĂ« Merge-in derisa disa zhvillues tĂ« vendosin "gishtin lart" nĂ« MR.

Përse është kjo e nevojshme?

Organizata jonë mund ta lejojë veten të blejë një licencë GitLab. Por, duke qenë se zhvillimi bëhet në një kontur të mbyllur pa qasje në internet, dhe ekziston një planifikim i rreptë i buxhetit, blerja e licencave self-managed me funksionalitetin e nevojshëm mund të zgjasë për shumë muaj, ndërsa ne duhet të punojmë tashmë.

Në fund, jemi të detyruar:

  • ose ta ndalojmĂ« krejtĂ«sisht Merge-in nĂ« degĂ«t e mbrojtura pĂ«r njĂ« pjesĂ« tĂ« zhvilluesve, por atĂ«herĂ« zhvilluesit qĂ« kanĂ« tĂ« drejtĂ« pĂ«r Merge do tĂ« kenĂ« konflikte gjatĂ« bashkimeve tĂ« MR-ve tĂ« tjerĂ«ve si njĂ« bonus;
  • ose t'u japim mundĂ«sinĂ« pĂ«r tĂ« bĂ«rĂ« bashkime tĂ« pakontrolluara me degĂ«n tuaj master pa rishikim tĂ« kodit, edhe nĂ«se Ă«shtĂ« njĂ« Junior, i punĂ«suar vetĂ«m dje.

Menjëherë fillova të kërkoj në Google, duke menduar se sigurisht dikush kishte bërë diçka të ngjashme (pa modifikim të kodit), por doli se një implementim i tillë në versionin e komunitetit ende nuk kishte qenë i pranishëm.

Schema e përgjithshme e punës

Si një shembull, do të konfigurojmë miratimet e kërkesave për bashkim në një depo testuese myapp:

  1. Do të krijojmë një token për qasje në API-në e GitLab (përmes të cilit do të marrim informacione për numrin e votave "për" dhe "kundër")
  2. Do të shtojmë token-in në variablat GitLab
  3. Do të ndalojmë Merge-in në rast të gabimeve në pipeline (nëse nuk ka mjaft vota "për")
  4. Do të konfigurojmë verifikimin e votave si pjesë e pipeline-it CI/CD
  5. Do të ndalojmë kryerjen e komiteteve në degët e mbrojtura, të gjitha ndryshimet i bëjmë vetëm përmes MR
  6. Do të verifikojmë se çfarë kemi arritur në fund

1. Krijojmë një token për qasje në API

HyjmĂ« nĂ« CilĂ«simet e pĂ«rdoruesit → Tokenet e qasjes dhe shĂ«nojmĂ« token-in:

Kontrolli i kodit në Gitlab CE: nëse nuk ka aprovime të Merge request, por shumë dëshiron.

Llogaria për marrjen e token-it
Qasja në API lejon të bëni praktikisht gjithçka me depozitat tuaja, prandaj rekomandoj të krijoni një llogari të veçantë Gitlab, t'i jepni asaj të drejtat minimale në depozitat tuaja (p.sh. Reporter) dhe të merrni token-in për këtë llogari.

2. Shtojmë token-in në variablat Gitlab

Për shembull, në hapin e mëparshëm kemi marrë token-in QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Hapim CilĂ«simet → CI/CD → Variablat → Shto variabĂ«l → GITLAB_TOKEN_FOR_CI

Kontrolli i kodit në Gitlab CE: nëse nuk ka aprovime të Merge request, por shumë dëshiron.

Në fund do të marrëim:

Kontrolli i kodit në Gitlab CE: nëse nuk ka aprovime të Merge request, por shumë dëshiron.

Kjo mund të bëhet si në një depo, ashtu edhe në një grup depozita.

3. Vendosni një ndalim për Merge, nëse nuk janë marrë miratimet e kolegëve pas përfundimit të shqyrtimit të kodit.

Në rastin tonë, ndalimi për Merge do të jetë se konvejeri i ndërtimit do të kthejë një gabim në rast të numrit të pamjaftueshëm të votave.

Hyni nĂ« CilĂ«simet → TĂ« PĂ«rgjithshme → KĂ«rkesat pĂ«r bashkim → Kontrolli i bashkimit dhe aktivizoni opsionin KonvejerĂ«t duhet tĂ« pĂ«rfundojnĂ« me sukses.

Kontrolli i kodit në Gitlab CE: nëse nuk ka aprovime të Merge request, por shumë dëshiron.

4. Konfiguroni pipeline-in

Nëse ende nuk keni krijuar një pipeline CI/CD për aplikacionin tuaj
Krijoni një skedë në rrënjën e depozitës .gitlab-ci.yml me përmbajtjet më themelore:

stages:
  - ndërtim
  - testim

variables:
  NEED_VOTES: 1

include:
  - remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

run-myapp:
  stage: ndërtim
  script: echo "Përshëndetje botë"

Depozitë e veçantë për konfigurimin e CI/CD
Unë do t'ju rekomandoja të krijoni një depo të veçantë, ku duhet të krijoni skedën myapp.gitlab-ci.yml për konfigurimin e pipeline-it. Kështu do të keni më shumë kontroll mbi qasjen e pjesëmarrësve që mund të ndryshojnë pipeline-in dhe të marrin një token qasje.

Pozita e skedĂ«s sĂ« re tĂ« pipeline-it duhet tĂ« tregojĂ« duke hyrĂ« nĂ« depozitĂ«n myapp — CilĂ«simet — CI/CD — KonvejerĂ«t — Rruga e personalizuar e konfigurimit CI — tregoni skedĂ«n e re, pĂ«r shembull myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Këshillë: përdorni një lintern për të bërë ndryshime në skedat GitLab CI
Edhe nëse punoni vetëm, një ndihmës i mirë është të punoni përmes MR, duke kaluar të gjitha ndryshimet tuaja të skedave të pipeline-it përmes linternit. Nëse gaboni në sintaksën e skedës YAML, kjo nuk do t'ju dështojë konvejerin e punës, por do të bllokojë thjesht Merge-in.

Shembuj të kontejnerëve me linters, që mund t'i integroni në pipeline-in tuaj:

hub.docker.com/r/gableroux/gitlab-ci-lint
hub.docker.com/r/sebiwi/gitlab-ci-validate

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)
    - për f në "${CI_FILES[@]}"; bëni
        gitlab-ci-validate $f;
      përfundoni;

Tani duhet të shtoni në pipeline-in tuaj disa parametra që gjithçka të funksionojë:

fazat:
- testi

variables:
NEED_VOTES: 1

include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

Variabli NEED_VOTES pĂ«rcakton sa ‘gishtat lart’ duhet tĂ« ketĂ« MR qĂ« tĂ« ketĂ« akses nĂ« Merge. NjĂ« vlerĂ« qĂ« Ă«shtĂ« njĂ« do tĂ« thotĂ« se ju mund ta miratoni vetĂ« MR-nĂ« tuaj, duke e ‘pĂ«lqyer’ atĂ«.

include lidh fazĂ«n testuese qĂ« verifikon numrin e ‘pĂ«lqimeve’.

Pipeline-i më i thjeshtë në shembullin myapp.gitlab-ci.yml
fazat:
- ndërto
- testi

variables:
NEED_VOTES: 0

include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

run-myapp:
stage: ndërtim
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ë rreth asaj që ndodh gjatë kontrollit:

  • Ă«shtĂ« vendosur njĂ« kufizim qĂ« kontrolli do tĂ« bĂ«het vetĂ«m gjatĂ« krijimit tĂ« MR nĂ« degĂ«t master ose release/*
  • duke pĂ«rdorur API-nĂ« e GitLab, marrim numrin e "like-Ă«ve" dhe "dislike-Ă«ve"
  • llogarisim diferencĂ«n midis komenteve pozitive dhe negative
  • nĂ«se diferenca Ă«shtĂ« mĂ« e vogĂ«l se vlera qĂ« ne kemi caktuar nĂ« NEED_VOTES, atĂ«herĂ« bllokojmĂ« mundĂ«sinĂ« pĂ«r tĂ« bĂ«rĂ« spajimin

5. Ndalohet kryerja e komiteteve në degët e mbrojtura

Përcaktojmë degët për të cilat duhet të kryejmë kontrollin e kodit dhe caktomë që punën me to mund ta bëjmë vetëm përmes MR.

PĂ«r kĂ«tĂ« hyjmĂ« nĂ« CilĂ«simet → Repo → DegĂ«t e Mbrojtura:

Kontrolli i kodit në Gitlab CE: nëse nuk ka aprovime të Merge request, por shumë dëshiron.

6. Kontrollojmë

Për të caktuar NEED_VOTES: 0

Krijojmë MR dhe vendosim "dislike".

Kontrolli i kodit në Gitlab CE: nëse nuk ka aprovime të Merge request, por shumë dëshiron.

Në loget e ndërtimit:

Kontrolli i kodit në Gitlab CE: nëse nuk ka aprovime të Merge request, por shumë dëshiron.

Tani vendosim "like" dhe nisim rivlerësimin:

Kontrolli i kodit në Gitlab CE: nëse nuk ka aprovime të Merge request, por shumë dëshiron.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster