ProHoster > Blogs > Administrācija > Koda pārskatÄ«Å”ana Gitlab CE: ja nav sapludināŔanas pieprasÄ«juma apstiprinājumu, bet es patieŔām vēlos

Koda pārskatÄ«Å”ana Gitlab CE: ja nav sapludināŔanas pieprasÄ«juma apstiprinājumu, bet es patieŔām vēlos

Koda pārskatÄ«Å”ana Gitlab CE: ja nav sapludināŔanas pieprasÄ«juma apstiprinājumu, bet es patieŔām vēlos

Viena no nepiecieÅ”amākajām funkcijām, kuras GitLab bezmaksas versijā nav, ir iespēja balsot pret repozitorija anulÄ“Å”anu un kontrolēt sapludināŔanas pieprasÄ«jumu (MR), izmantojot obligāto koda pārskatÄ«Å”anu.

Minimālo funkcionalitāti veiksim paÅ”i ā€“ Merge aizliegsim, kamēr vairāki izstrādātāji MR neparādÄ«s Ä«kŔķi.

Kāpēc tas vispār ir vajadzīgs?

MÅ«su organizācija var viegli atļauties iegādāties GitLab licenci. Bet, tā kā izstrāde notiek slēgtā kontÅ«rā bez piekļuves internetam un ir stingra budžeta plānoÅ”ana, paÅ”pārvaldÄ«to licenču iegāde ar nepiecieÅ”amo funkcionalitāti var ievilkties vairākus mēneÅ”us, taču darbs ir jādara tagad.

Rezultātā jums ir:

  • vai pilnÄ«bā aizliegt Merge aizsargātās filiālēs dažiem izstrādātājiem, bet tad izstrādātāji, kuriem ir tiesÄ«bas apvienot, saņem konfliktus, apvienojot citu cilvēku MR kā bonusu;
  • vai dodiet iespēju veikt nekontrolētu sapludināŔanu ar savu galveno filiāli bez koda pārskatÄ«Å”anas, pat ja tas ir Junior, kurÅ” tika pieņemts darbā tikai vakar.

Pirmais, ko izdarÄ«ju, bija Google, uzskatot, ka kāds noteikti jau kaut ko lÄ«dzÄ«gu ir izdarÄ«jis (bez koda modifikācijas), taču izrādÄ«jās, ka kopienas versijā tādas ievieÅ”anas vēl nav.

Vispārējā darba shēma

Piemēram, konfigurēsim sapludināŔanas pieprasÄ«jumu apstiprinājumus testa repozitorijā myapp:

  1. Izveidosim tokenu piekļuvei GitLab API (caur to saņemsim informāciju par balsu skaitu "par" un "pret")
  2. Pievienosim marķieri GitLab mainīgajiem
  3. Atspējosim sapludināŔanu, ja konveijerā rodas kļūdas (ja nav pietiekami daudz pozitÄ«vu balsojumu)
  4. Iestatīsim balsojumu verifikāciju kā daļu no CI/CD konveijera
  5. Mēs aizliedzam uzņemties saistības aizsargātās filiālēs; visas izmaiņas tiek veiktas tikai ar MR starpniecību
  6. Pārbaudīsim, kas beigās notika

1. Izveidojiet pilnvaru, lai piekļūtu API

Dodieties uz Lietotāja iestatÄ«jumi ā†’ Piekļuves pilnvaras un pierakstiet marÄ·ieri:

Koda pārskatÄ«Å”ana Gitlab CE: ja nav sapludināŔanas pieprasÄ«juma apstiprinājumu, bet es patieŔām vēlos

Konts marÄ·iera saņemÅ”anai
API piekļuve ļauj ar savām krātuvēm darÄ«t gandrÄ«z jebko, tāpēc iesaku izveidot atseviŔķu Gitlab kontu, pieŔķirot tam minimālas tiesÄ«bas uz jÅ«su krātuvēm (piemēram, Reporter) un iegÅ«t Å”im kontam marÄ·ieri.

2. Pievienojiet marķieri Gitlab mainīgajiem

Piemēram, iepriekŔējā darbÄ«bā mēs saņēmām marÄ·ieri QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Atveriet IestatÄ«jumi ā†’ CI/CD ā†’ MainÄ«gie ā†’ Pievienot mainÄ«go ā†’ GITLAB_TOKEN_FOR_CI

Koda pārskatÄ«Å”ana Gitlab CE: ja nav sapludināŔanas pieprasÄ«juma apstiprinājumu, bet es patieŔām vēlos

Rezultātā mēs iegūstam:

Koda pārskatÄ«Å”ana Gitlab CE: ja nav sapludināŔanas pieprasÄ«juma apstiprinājumu, bet es patieŔām vēlos

To var izdarīt vai nu vienā repozitorijā, vai repozitoriju grupā.

3. Uzliekam aizliegumu Merge, ja pēc koda izskatÄ«Å”anas netiek saņemts kolēģu apstiprinājums.

Mūsu gadījumā sapludināŔanas aizliegums būs tāds, ka montāžas cauruļvads atgriezīs kļūdu, ja nebūs pietiekami daudz balsu.

Dodieties uz IestatÄ«jumi ā†’ VispārÄ«gi ā†’ SapludināŔanas pieprasÄ«jumi ā†’ SapludināŔanas pārbaudes un iespējojiet opciju Montāžas lÄ«nijām jāpabeidz veiksmÄ«gi.

Koda pārskatÄ«Å”ana Gitlab CE: ja nav sapludināŔanas pieprasÄ«juma apstiprinājumu, bet es patieŔām vēlos

4. Cauruļvada uzstādīŔana

Ja vēl neesat izveidojis CI/CD konveijeru savai lietojumprogrammai
Izveidojiet failu repozitorija saknē .gitlab-ci.yml ar visvienkārŔāko saturu:

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"

AtseviŔķs repozitorijs CI/CD konfigurācijai
Es ieteiktu izveidot atseviŔķu repozitoriju, kurā ir jāizveido fails myapp.gitlab-ci.yml, lai konfigurētu konveijera. Tādā veidā jÅ«s varat labāk kontrolēt to dalÄ«bnieku piekļuvi, kuri var mainÄ«t bÅ«vÄ“Å”anas konveijeru un saņemt piekļuves pilnvaru.

Jaunā konveijera faila atraŔanās vieta būs jānorāda, dodoties uz myapp repozitoriju - Iestatījumi - CI/CD - Montāžas līnijas - Pielāgotas CI konfigurācijas ceļŔ - norādiet jauno failu, piem. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Padoms. Izmantojiet linteri, lai veiktu izmaiņas GitLab CI failos
Pat ja strādājat vienatnē, darbs, izmantojot MR, bÅ«s labs palÄ«gs, veicot visas izmaiņas konveijera failos, izmantojot lÄ«niju. Ja pieļausit kļūdu YAML faila sintaksē, tas nepārtrauks jÅ«su ražoÅ”anas cauruļvadu, bet vienkārÅ”i bloķēs sapludināŔanu.

Piemērs konteineriem ar ieliktņiem, kurus varat iebūvēt savā cauruļvadā:

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

Un verifikācijas posma piemērs:

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;

Atliek savam cauruļvadam pievienot dažus parametrus, lai tas darbotos:

stages:
- test

variables:
NEED_VOTES: 1

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

MainÄ«gais NEED_VOTES nosaka, cik ā€œÄ«kŔķiemā€ jābÅ«t MR, lai sapludināŔana bÅ«tu pieejama. VērtÄ«ba, kas vienāda ar vienu, nozÄ«mē, ka jÅ«s pats varat apstiprināt savu MR, atzÄ«mējot to ar ā€œpatÄ«kā€.

iekļaut ietver testa posmu, kurā tiek pārbaudÄ«ts ā€œpatÄ«kā€ atzÄ«mju skaits.

VienkārŔākais cauruļvads, izmantojot myapp.gitlab-ci.yml piemēru
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

Saturs 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/.*$/'

PlaŔāka informācija par to, kas notiek verifikācijas laikā:

  • ir ierobežojums, ka pārbaude tiks veikta tikai veidojot MR galvenajā vai release/* zaros
  • izmantojot GitLab API, mēs iegÅ«stam ā€œpatÄ«kā€ un ā€œnepatÄ«kā€ skaitu.
  • aprēķināt atŔķirÄ«bu starp pozitÄ«vajām un negatÄ«vajām atbildēm
  • ja starpÄ«ba ir mazāka par vērtÄ«bu, ko iestatÄ«jām NEED_VOTES, mēs bloķējam sapludināŔanas iespēju

5. Aizliegt saistības aizsargātajās filiālēs

Mēs definējam filiāles, kurām mums jāveic kodu pārskatÄ«Å”ana, un norādām, ka ar tām var strādāt tikai caur MR.

Lai to izdarÄ«tu, dodieties uz IestatÄ«jumi ā†’ Repozitorijs ā†’ Aizsargātās filiāles:

Koda pārskatÄ«Å”ana Gitlab CE: ja nav sapludināŔanas pieprasÄ«juma apstiprinājumu, bet es patieŔām vēlos

6. Pārbaudiet

Iestatījums NEED_VOTES: 0

Uztaisām MR un uzliekam ā€œnepatÄ«kā€.

Koda pārskatÄ«Å”ana Gitlab CE: ja nav sapludināŔanas pieprasÄ«juma apstiprinājumu, bet es patieŔām vēlos

Būvniecības žurnālos:

Koda pārskatÄ«Å”ana Gitlab CE: ja nav sapludināŔanas pieprasÄ«juma apstiprinājumu, bet es patieŔām vēlos

Tagad ielieciet "patīk" un sāciet pārbaudīt vēlreiz:

Koda pārskatÄ«Å”ana Gitlab CE: ja nav sapludināŔanas pieprasÄ«juma apstiprinājumu, bet es patieŔām vēlos

Avots: www.habr.com

Pievieno komentāru