ProHoster > Blog > Administrimi > Rishikimi i kodit në Gitlab CE: nëse nuk ka aprovime për Merge request, por shumë e do

Rishikimi i kodit në Gitlab CE: nëse nuk ka aprovime për Merge request, por shumë e do

Rishikimi i kodit në Gitlab CE: nëse nuk ka aprovime për Merge request, por shumë e do

Një nga funksionet më të nevojshme që nuk e ka versioni falas i GitLab është mundësia për të votuar kundër anullimit të repositorit duke kontrolluar kërkesat për bashkim (MR) duke përdorur rishikimin e detyrueshëm të kodit.

Ne do ta krijojmë funksionalitetin minimal vetë - do ta ndalojmë bashkimin derisa disa zhvillues të japin "për" për MR.

Pse është kjo e nevojshme?

Organizata jonë e lejon në plotësi blerjen e licencës GitLab. Por, pasi zhvillimi bëhet në një ambient të mbyllur pa akses në internet, dhe është planifikuar me rigorozitet buxheti, blerja e licencave self-managed me funksionalitetin e nevojshëm mund të zgjasë për shumë muaj, ndërkohë që duhet të punojmë tashmë.

E në fund duhet:

  • ose të ndalojmë plotësisht bashkimin në degët e mbrojtura për disa zhvillues, por atëherë zhvilluesit që kanë të drejtë për të bashkuar përfundojnë me konflikte kur përpiqen të bashkojnë MR të tjerë si një bonus;
  • ose të japim mundësi për të bërë bashkime pa kontroll me degën tuaj kryesore pa rishikim të kodit, edhe nëse është një Junior, i saposhkruar dje.

Isha drejtë për drejtë në internet, duke menduar se sigurisht dikush kishte bërë diçka të tillë (pa ndihmuar kodin), por rezultoi se një implementim i tillë në versionin community nuk kishte qenë ende i disponueshëm.

Skema e përgjithshme e punës

Si një shembull, do të konfigurojmë aprovimet e kërkesës për bashkim në një repositor testues. myapp:

  1. Do të krijojmë një token për akses në API-në e GitLab (përmes të cilit do të marrim informacionin mbi numrin e votave "për" dhe "kundër")
  2. Do të shtojmë tokenin në variablat e GitLab
  3. Do të ndalojmë bashkimin në rast gabimesh në pipeline (nëse numri i votave "për" është i pamjaftueshëm)
  4. Do të konfigurojmë kontrollin e votave si pjesë të pipeline-it CI/CD
  5. Do të ndalojmë kryerjen e komiteteve në degët e mbrojtura, të gjitha ndryshimet do të bëhen vetëm nëpërmjet MR
  6. Do të kontrollojmë se çfarë kemi arritur në fund

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

Hyn në Cilësimet e përdoruesit → Tokenet e aksesit dhe regjistro tokenin:

Rishikimi i kodit në Gitlab CE: nëse nuk ka aprovime për Merge request, por shumë e do

Llogaria për marrë tokenin
Aksesi në API lejon kryerjen e pothuajse çdo gjëje me repositorët tuaj, prandaj rekomandoj të krijoni një llogari të veçantë GitLab, t'i jepni asaj të drejta minimale në repositorët tuaj (për shembull, Reporter) dhe të merrni tokenin për këtë llogari.

2. Shtojmë tokenin në variablat e GitLab

Për shembull, në hapin e mëparshëm kemi marrë tokenin QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Hap Cilësimet → CI/CD → Variablat → Shto variablin → GITLAB_TOKEN_FOR_CI

Rishikimi i kodit në Gitlab CE: nëse nuk ka aprovime për Merge request, por shumë e do

Kështu do të marrim:

Rishikimi i kodit në Gitlab CE: nëse nuk ka aprovime për Merge request, por shumë e do

Kjo mund të bëhet si në një repositor ashtu edhe në një grup repositorësh.

3. Vendosim ndalimin e bashkimit, nëse nuk janë marrë aprovimet e kolegëve pas rishikimit të kodit

Në rastin tonë ndalimi i bashkimit do të jetë se procesi i ndërtimit do të kthejë një gabim në rast numri i pamjaftueshëm i votave.

Hyn në Cilësimet → Themelore → Kërkesat për bashkim → Kontrollimet e bashkimit dhe aktivizo opsionin "Linjat e ndërtimit duhet të ekzekutohen me sukses".

Rishikimi i kodit në Gitlab CE: nëse nuk ka aprovime për Merge request, por shumë e do

4. Konfigurojmë pipeline-in

Nëse ende nuk keni realizuar një pipeline CI/CD për aplikacionin tuaj
Krijojmë një skedar në rrënjën e repositorit .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"

Repositori i veçantë për konfigurimin e CI/CD
Do të rekomandoja të krijoni një repositor të veçantë, në të cilin duhet të krijoni skedarin myapp.gitlab-ci.yml për të konfiguruar pipeline-in. Kështu do të keni më shumë kontroll mbi aksesin e pjesëmarrësve që mund të ndryshojnë pipeline-in e ndërtimit dhe të marrin tokenin e aksesit.

Pozita e skedarit të ri të pipeline-it duhet të tregoni duke hyrë në repositorin myapp — Cilësimet — CI/CD — Linjat e ndërtimit — Rruga e personalizuar e konfigurimit të CI — tregon skedarin e ri, për shembull myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Këshillë: përdorni linternë për të bërë ndryshime në skedarët e 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ë skedarëve të pipeline-it përmes linternës. Nëse bëni një gabim në sintaksën e skedarit YAML, kjo nuk do t'ju prishë pipeline-in tuaj të punës, por thjesht do të bllokojë bashkimin.

Shembuj kontejnerësh me linternë që mund t’i integroheni 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)
    - for f in "${CI_FILES[@]}"; do
        gitlab-ci-validate $f;
      done;

Ka mbetur të shtoni disa parametra në pipeline-in tuaj, për ta bërë atë të funksionojë:

stadi:
- provim

variables:
NEED_VOTES: 1

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

Variabla NEED_VOTES përcakton se sa "për" duhet të ketë MR, për ta bërë bashkimin të mundshëm. Një vlerë e barabartë me një nënkupton që ju mund ta miratoni vetë MR tuaj, duke i dhënë 'like' atij.

Include e përfshin fazën e testit, e cila kontrollon numrin e 'like'-eve.

Pipeline më i thjeshtë si një shembull në myapp.gitlab-ci.yml
stadi:
- ndihmo
- provim

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ë rreth asaj që ndodh gjatë rishikimit:

  • është vendosur një kufizim që rishikimi do të kryhet vetëm kur krijohet një MR në degët master ose release/*
  • duke përdorur API-në e GitLab, marrim numrin e 'like'-eve dhe 'dislike'-eve
  • llogarisim diferencën midis reagimeve pozitive dhe negative
  • nëse diferenca është më e vogël se vlera që kemi caktuar në NEED_VOTES, atëherë bllokojmë mundësinë e bashkimit

5. Ndaluam commit-et në degë të mbrojtura

Përcaktojmë degët për të cilat duhet të kryejmë rishikimin e kodit dhe tregojmë se punimi me to mund të bëhet vetëm përmes MR.

Për këtë shkojmë në Cilësimet → Repozitori → Degët e Mbrojtura:

Rishikimi i kodit në Gitlab CE: nëse nuk ka aprovime për Merge request, por shumë e do

6. Kontrollojmë

Caktojmë NEED_VOTES: 0

Krijojmë një MR dhe vendosim ‘dislike’.

Rishikimi i kodit në Gitlab CE: nëse nuk ka aprovime për Merge request, por shumë e do

Në log-et e ndërtimit:

Rishikimi i kodit në Gitlab CE: nëse nuk ka aprovime për Merge request, por shumë e do

Tani vendosim ‘like’ dhe запускаем повторную проверку:

Rishikimi i kodit në Gitlab CE: nëse nuk ka aprovime për Merge request, por shumë e do

Burimi: habr.com

Bleni hostim të besueshëm për faqe me mbrojtje nga DDoS, serverë VPS VDS 🔥 Bleni hostim të besueshëm për faqe me mbrojtje nga DDoS, serverë VPS VDS | ProHoster