Преглед на кода в Gitlab CE: ако няма одобрения за искане за сливане, но наистина искам

Една от най-необходимите функции, която не е в безплатната версия на GitLab, е възможността да гласувате срещу нулирането на хранилището, за да контролирате заявката за сливане (MR), като използвате задължителния преглед на кода.

Сами ще направим минималната функционалност - ще деактивираме Merge, докато няколко разработчици не дадат „палец нагоре“ на MR.

Защо изобщо е това?

Нашата организация може да си позволи да закупи лиценз за GitLab. Но тъй като разработката се извършва в затворен цикъл без достъп до интернет и има стриктно бюджетно планиране, закупуването на самоуправляеми лицензи с необходимата функционалност може да отнеме много месеци и трябва да работите сега.

В резултат на това трябва:

• или напълно забранете сливането в защитени клонове за някои разработчици, но тогава разработчиците, които имат право на сливане, получават конфликти при сливане на MR на други хора като бонус;
• или ви позволяват да правите неконтролирани сливания с вашия главен клон без преглед на кода, дори ако това е Junior, който току-що се е установил вчера.

Първото нещо, което направих, беше да потърся в Google, вярвайки, че някой вече е правил нещо подобно (без да прецизира кода), но се оказа, че все още няма такава реализация във версията на общността.

Обща схема на работа

Като пример, нека настроим одобрения на заявки за сливане в тестово хранилище моето приложение:

1. Да създадем токен за достъп до GitLab API (чрез него ще получаваме информация за броя на гласовете за и против)
2. Добавете токен към променливите на GitLab
3. Деактивирайте сливането, ако има грешки в процеса (ако няма достатъчно гласове „за“)
4. Настройте проверката на гласа като част от CI/CD тръбопровода
5. Ще забраним извършването на ангажименти към защитени клонове, ние правим всички промени само чрез MR
6. Нека да проверим какво се е случило в крайна сметка

1. Създайте токен за достъп до API

Отидете на Потребителски настройки → Токени за достъп и запишете токена:

Акаунт за получаване на токена
API достъпът ви позволява да правите почти всичко с вашите хранилища, така че предлагам да създадете отделен акаунт в Gitlab, да му дадете минимални права за вашите хранилища (като Reporter) и да получите токен за този акаунт.

2. Добавете токена към променливите на Gitlab

Например в предишната стъпка получихме токен QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Отворете Настройки → CI/CD → Променливи → Добавяне на променлива → GITLAB_TOKEN_FOR_CI

В резултат на това получаваме:

Това може да се направи както в едно хранилище, така и в група от хранилища.

3. Поставяме забрана на 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, за да настроите тръбопровода. По този начин можете по-добре да контролирате достъпа на участниците, които могат да променят конвейера за изграждане и да получат токен за достъп.

Местоположението на новия тръбопроводен файл ще трябва да бъде посочено, като отидете в хранилището на myapp - Настройки - CI / CD - Сглобяеми линии - Персонализиран CI конфигурационен път - посочете нов файл, например myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Съвет: Използвайте линтер, за да правите промени в GitLab CI файлове
Дори и да работите сами, работата чрез MR ще ви бъде добър помощник, изпълнявайки всичките си промени в тръбопроводните файлове през линтера. Ако направите грешка в синтаксиса на YAML файла, това няма да ви позволи да прекъснете работния конвейер, а просто ще блокира Merge.

Пример за контейнери с линтери, които можете да вградите във вашия конвейер:

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

И пример за етапа на валидиране:

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;

Остава да добавите няколко параметъра към вашия конвейер, за да работи:

stages:
- test

variables:
NEED_VOTES: 1

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

Променливата NEED_VOTES определя колко "палеца нагоре" MR трябва да има, за да е налично сливането. Стойност едно означава, че вие ​​сами можете да одобрите вашия MR, като го „харесате“.

include включва тестовия етап, който проверява броя на "харесванията".

Най-простият конвейер, използващ myapp.gitlab-ci.yml като пример
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

Съдържание на 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/.*$/'


Научете повече за това какво се случва при проверка:

• зададено е ограничението, че проверката ще бъде само при създаване на MR в master или release /* клонове
• използвайки GitLab API, вземете броя на „харесванията“ и „нехаресванията“
• изчислете разликата между положителните и отрицателните отговори
• ако разликата е по-малка от стойността, която сме задали в NEED_VOTES, тогава блокираме възможността за сливане

5. Деактивирайте ангажиментите към защитени клонове

Ние определяме клоновете, за които трябва да извършим преглед на кода, и посочваме, че с тях може да се работи само чрез MR.

За да направите това, отидете на Настройки → Хранилище → Защитени клонове:

6. Проверка

Задайте NEED_VOTES: 0

Правим MR и поставяме "dislike".

В регистрационните файлове за изграждане:

Сега поставете „харесвам“ и изпълнете повторна проверка:

Източник: www.habr.com