Koodikontroll Gitlab CE-s: kui Merge request'i kinnitust ei ole, aga väga tahaks

Üks tasuta GitLabi versioonis puuduvatest kõige vajalikumatest funktsioonidest on võimalus hääletada repositoriumi nullimise vastu, kontrollides Merge requesti (MR) kohustusliku koodivaatamise abil.

Loome minimaalset funktsionaalsust ise – keelame Merge, kuni mitu arendajat ei ole pannud MR-ile „ülemise sõrme”.

Miks see üldse vajalik on?

Meie organisatsioon suudab endale lubada GitLabi litsentsi ostmist. Kuid kuna arendustööd tehakse suletud keskkonnas ilma internetiühenduseta ning eelarve planeerimine on rangelt reguleeritud, võib litsentside ostmine vajalikku funktsionaalsust haldaval viisil kesta mitu kuud, kuid tööle tuleb hakata juba praegu.

Tuleb leppida, et:

• kas keelatakse Merge kaitstud harudesse osadele arendajatele täiesti, kuid siis saavad need arendajad, kellel on Merge'i õigus, boonuseks konfliktid teiste MR-ide liitmisel;
• või antakse võimalus teha kontrollimatuid liitumisi teie peamisse harusse ilma koodivaatamiseta, isegi kui see on alles eile tööle tõusnud noor arendaja.

Esimese asjana hakkasin Google'it kasutama, arvestades, et kindlasti on keegi midagi sarnast juba teinud (ilma koodi täiendamata), kuid selgus, et sellist lahendust kogukonna versioonis polnud veel olnud.

Üldine tööprotsess

Võtame näiteks Merge requesti kinnitused testrepositoriosse seadistamise. myapp:

1. Loome API-juurdepääsuks tokeni GitLabis (selle kaudu saame teavet „poolt” ja „vastu” hääli).
2. Lisame tokeni GitLabi muutujatesse.
3. Keelame Merge, kui tootmisprotsessis on vigu (kui hääli „poolt” on liiga vähe).
4. Seame hääletamise kontrolli CI/CD tootmisprotsessi osaks.
5. Keelame kaitstud harudesse commit'i tegemise, kõik muudatused tehakse ainult MRide kaudu.
6. Kontrollime, mis meil lõpuks välja tuli.

1. Loome API-juurdepääsu tokeni.

Siseneme Kasutaja seadistustesse → Juurdepääsutokenid ja kirjutame tokeni üles:

Konto tokeni saamiseks.
API-juurdepääs võimaldab peaaegu kõike teie repositoritega teha, seetõttu soovitan luua eraldi GitLabi konto, anda sellele minimaalset õigust teie repositoritele (näiteks Reporter) ja saada token selle konto jaoks.

2. Lisame tokeni GitLabi muutjatesse.

Näiteks eelmisel sammul saime tokeni. QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Avame Seaded → CI/CD → Muutujad → Lisa muutuja → GITLAB_TOKEN_FOR_CI

Lõpuks saame:

Seda saab teha nii ühes hoidlas kui ka hulgi hoidlates.

3. Paneme merge'i keeldu, kui kolleegide heakskiitu ei saadud pärast koodivaatlust.

Meie puhul tähendab merge'i keeld seda, et kogumise konveier tagastab vea, kui hääli on liiga vähe.

Siseneme Seaded → Üldine → Ühinemise taotlused → Ühinemise kontrollid ja lülitame sisse valiku 'Kogumislid peaksid olema edukalt lõpule viidud'.

4. Seame pipeline'i

Kui te pole veel oma rakenduse CI/CD konveierit loonud
Loome hoidla juures faili .gitlab-ci.yml lihtsa sisuga:

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 "Tere maailm"

Eraldi hoidla CI/CD konfiguratsiooni jaoks
Soovitan luua eraldi hoidla, kus on vajalik luua fail myapp.gitlab-ci.yml konveieri seadistamiseks. Nii saate paremini kontrollida osalejate juurdepääsu, kes saavad konveieri koostamist muuta ja pääsukoodi saada.

Uue konveieri faili asukoht tuleb määrata, minnes hoidla myapp — Seaded — CI/CD — Kogumislid — Kohandatud CI konfiguratsiooni tee — märkida uus fail, näiteks myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Näpunäide: kasutage linterit, et muuta GitLab CI-faile
Isegi kui töötate üksi, on kasulik töötada MR kaudu, lastes kõik oma konveieri muudatused läbi linteri. Kui teete YAML-faili süntaksivigu, ei riku see teie töökonveierit, vaid lihtsalt blokeerib merge'i.

Näide linteritest, mida saate oma konveierisse inteerida:

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

Ja näide kontrolli etapist:

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;

Rohkem tuleb teie konveierisse lisada mõned parameetrid, et kõik toimiks:

etapid:
- test

variables:
NEED_VOTES: 1

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

Muutuja NEED_VOTES määrab, kui palju "ülestõusmisi" peab MR-l olema, et merge oleks võimalik. Üks väärtus tähendab, et saate ise oma MR-i heaks kiita, "meeldides" sellele.

include ühendab testi etapi, mis kontrollib "meeldimiste" arvu.

Lihtne töövoog myapp.gitlab-ci.yml näitel
etapid:
- ehitada
- 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
skeem:
- echo CI_MERGE_REQUEST_TARGET_BRANCH_NAME $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
- java HelloWorld.java

Sisu check-approve.gitlab-ci.yml
ci-mr:
etapp: test
skeem:
- 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} Üles hääled = 1, alla hääled = -1, MR OK kui hääled >=${NEED_VOTES_REAL}"
- if [ "${MR_VOTES}" -ge "$(expr ${NEED_VOTES_REAL})" ];
siis
echo "MR OK";
muul juhul
echo "MR VIGA: Vaja rohkem hääli";
exit 1;
fi
pilt: laptevss\/gitlab-api-util
reeglid:
- if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ \/^release\/.*$\/'


Lisainfot selle kohta, mis toimub kontrollimise ajal:

• on seatud piirang, et kontroll toimub ainult siis, kui MR luuakse harudesse master või release/*
• kasutades GitLab API-d, saame teada «meeldimiste» ja «mitte-meeldimiste» arvu
• arvutame positiivsete ja negatiivsete tagasiside vahe
• kui vahe on väiksem, kui meie poolt määratud väärtus NEED_VOTES, siis blokeerime sulgemise võimaluse

5. Keelame commit'id kaitstud harudesse

Määrame harud, mille puhul peame teostama koodikontrolli ja märkime, et nendega saab töötada ainult MR-i kaudu.

Selleks liigume Seaded → Repositorium → Kaitstud harud:

6. Kontrollime

Seame NEED_VOTES: 0

Teeme MR ja paneme «mitte-meeldib».

Kogumise logides:

Nüüd paneme «meeldib» ja käivitame uuesti kontrolli:

Allikas: habr.com