Koodikontroll Gitlab CE-s: kui sul pole sulandamise taotluste heakskiitu, kuid tahad väga.

Üks kõige vajalikke funktsioone, mida tasuta GitLabis ei ole, on võimalus hääletada vastu repositooriumi nullimisele, kontrollides Merge request (MR) kasutades kohustuslikku koodikontrolli.

Loodame kõige lihtsama funktsionaalsuse — keelame Merge, kuni mitu arendajat on MR-le 'ülespoole' hääletanud.

Miks see üldse vajalik on?

Meie organisatsioon suudab täiesti endale lubada GitLabi litsentsi ostmist. Kuid kuna arendustööd käivad suletud keskkonnas ilma internetiühenduseta ja on ranged eelarve planeerimised, võib vajalikul funktsionaalsusel tugineva iseseisva halduskeskkonna litsentside ostmine võtta mitu kuud, kuid meil tuleb alustada juba praegu.

Seetõttu tuleb teha järgmist:

• kas keelata Merge kaitstud harudel osadele arendajatele täielikult, kuid siis saavad Merge õigused omavad arendajad boonuseks konfliktid teiste MR-ide sulandumisel;
• või anda võimalus teha kontrollimatuid sulandumisi teie põhiharuga, isegi kui see on alles eile tööle hakanud Junior.

Esimese asjana hakkasin googeldama, arvates, et keegi on kindlasti midagi sellist juba teinud (ilma koodi kohandamiseta), kuid selgus, et sellist rakendust kogukonna versioonis veel ei olnud.

Üldine tööskeem

Näitena seadistame Merge request'i heakskiidu testrepositorios myapp:

1. Loome API GitLab'i juurdepääsuks tokeni (selle kaudu saame teavet häälte arvu kohta "poolt" ja "vastu")
2. Lisame tokeni GitLab'i muutujatesse
3. Keelame Merge, kui torustus on vigu (kui häälte arv "poolt" on ebapiisav)
4. Seadistame häälte kontrollimise CI/CD torustiku osana
5. Keelame teatud harudesse commitite tegemise, kõik muudatused teeme ainult MR kaudu
6. Kontrollime, mis lõpuks välja tuli

1. Loome API juurde pääsemiseks tokeni

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

Konto tokeni saamiseks
API kasutamine võimaldab teha praktiliselt kõike teie repodega, seega soovitan luua eraldi GitLab'i konto, anda sellele minimaalset juurdepääsu teie repositoritele (näiteks Reporter) ja saada selle konto jaoks token.

2. Lisame tokeni GitLab'i muutujatesse

Näiteks, eelmisel sammul saime tokeni QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Открываем Настройки → CI/CD → Переменные → Добавить переменную → GITLAB_TOKEN_FOR_CI

В итоге получим:

Это можно сделать как на одном репозитории, так и на группе репозиториев.

3. Ставим запрет на Merge, если не получены одобрения коллег после проведенного code review

В нашем случае запретом на Merge будет являться то, что сборочный конвейер вернет ошибку при недостаточном количестве голосов.

Заходим в Настройки → Основные → Запросы на слияние → Проверки слияния и включаем опцию Сборочные линии должны успешно выполниться.

4. Настраиваем пайплайн

Если вы еще не делали CI/CD конвейер для вашего приложения
Создаем в корне репозитория файл .gitlab-ci.yml с простейшим содержанием:

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"

Отдельный репозиторий для конфигурации CI/CD
Я бы рекомендовал сделать отдельный репозиторий, в котором необходимо создать файл myapp.gitlab-ci.yml для настройки конвейера. Так вы сможете лучше контролировать доступ участников, которые могут изменить конвейер сборки и получить токен доступа.

Uue toru faili asukoht tuleb määrata, minnes myapp'i — Seaded — CI/CD — Kogumislait — Kohandatud CI konfiguratsiooni tee — määrake uus fail, näiteks myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Soovitus: kasutage lintijat, et teha muudatusi GitLabi CI failides
Isegi kui töötate üksi, võib MR kaudu töötamine olla hea abiline, käivitades kõik teie torustiku failide muudatused lintijas. Kui teete YAML faili süntaksis vea, ei riku see teie töötoru, vaid lihtsalt blokeerib Merge'i.

Näide lintijatega konteineritest, mida saate oma torustikku integreerida:

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

Ja näide kontrollietapist:

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;

On jäänud lisada teie torustikku mõned parameetrid, et kõik töötaks:

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 „ülespoole näpuga“ peab MR-l olema, et sul oleks võimalik Merge'i teha. Väärtus, mis on võrdsed ühega, tähendab, et saad ise oma MR-i heaks kiita, „meeldides“ sellele.

include lisab testi etapi, mis kontrollib „meeldimiste“ arvu.

Lihtsaim pipelines näite põhjal myapp.gitlab-ci.yml
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
skript:
- 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
skript:
- 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} Ülemine hääl = 1, alam hääl = -1, MR on heakskiidetud, kui hääled >=${NEED_VOTES_REAL}"
- if [ "${MR_VOTES}" -ge "$(expr ${NEED_VOTES_REAL})" ];
then
echo "MR OK";
muud
echo "MR VIGA Vajab 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/.*$/'


Rohkem teavet selle kohta, mis juhtub kontrollimise ajal:

• seatud piirang, et kontrollimine toimub ainult siis, kui MR luuakse harudesse master või release/*
• kasutades GitLabi API-d, saame „meeldimiste“ ja „mitte meeldimiste“ arvu
• arvutame positiivsete ja negatiivsete vastuste vahelise erinevuse
• kui erinevus on väiksem kui meie määratud väärtus NEED_VOTES-s, blokeerime võimaluse sulanduda

5. Keelame commitid kaitstud harudesse

Määrame harud, mille jaoks peame korraldama koodiarvustusi ja märgime, et nendega saab töötada ainult MR-i kaudu.

Selleks läheme Seaded → Reposiit → Kaitstud harud:

6. Kontrollime

Seame NEED_VOTES: 0

Teeme MR-i ja paneme „mitte meeldib“.

Kogumislugedes:

Nüüd paneme „meeldib“ ja käivitame uut kontrolli:

Allikas: habr.com