ProHoster > блог > Администрација > Преглед на код во Gitlab CE: ако нема одобренија за барање за спојување, но навистина сакам

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

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

Една од најпотребните функции што ја нема во бесплатната верзија на GitLab е можноста да се гласа против нулањето на складиштето за да се контролира барањето за спојување (MR) со користење на задолжителниот преглед на кодот.

Сами ќе ја направиме минималната функционалност - ќе го оневозможиме Спојувањето додека неколку програмери не ѝ одговорат на MR.

Зошто е ова воопшто?

Нашата организација може да си дозволи да купи GitLab лиценца. Но, бидејќи развојот се изведува во затворена јамка без пристап до Интернет и има строго буџетско планирање, купувањето лиценци за самостојно управување со потребната функционалност може да потрае многу месеци, а вие треба да работите сега.

Како резултат на тоа, треба да:

  • или целосно да го забрани Merge во заштитени гранки за некои програмери, но потоа програмерите кои имаат право на Merge добиваат конфликти кога спојуваат туѓи MR како бонус;
  • или ви дозволуваат да правите неконтролирано спојување со вашата главна филијала без преглед на кодот, дури и ако тоа е Јуниор кој штотуку се населил вчера.

Првото нешто што го направив беше гугл, верувајќи дека некој веќе направил нешто слично (без да го рафинирам кодот), но се покажа дека сè уште нема таква имплементација во верзијата на заедницата.

Општа шема на работа

Како пример, ајде да поставиме одобренија за барање за спојување на тест складиште myapp:

  1. Ајде да создадеме токен за пристап до GitLab API (преку него ќе добиваме информации за бројот на гласови за и против)
  2. Додадете токен во променливите на GitLab
  3. Оневозможете го спојувањето ако има грешки во нафтоводот (ако нема доволно гласови „за“)
  4. Поставете валидација на гласовите како дел од цевководот CI/CD
  5. Ќе забраниме да се обврзуваме на заштитени филијали, сите промени ги правиме само преку MR
  6. Ајде да провериме што се случи на крајот

1. Направете токен за пристап до API

Одете во Кориснички поставки → Пристап до токени и запишете го токенот:

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

Сметка за да го прими токенот
Пристапот до API ви овозможува да правите речиси сè со вашите складишта, затоа ви предлагам да креирате посебна сметка на Gitlab, да му дадете минимални права на вашите складишта (како Reporter) и да добиете токен за таа сметка.

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

На пример, во претходниот чекор, добивме токен QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Отворете Поставки → CI/CD → Променливи → Додај променлива → GITLAB_TOKEN_FOR_CI

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

Како резултат, добиваме:

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

Ова може да се направи и на едно складиште и на група складишта.

3. Ставаме забрана за Merge доколку не се добие одобрение од колегите по прегледот на кодот

Во нашиот случај, забраната за Merge ќе биде дека монтажниот гасовод ќе врати грешка ако нема доволно гласови.

Одете во Поставки → Општо → Барања за спојување → Проверки за спојување и овозможете ја опцијата Линиите за склопување мора успешно да работат.

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

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 одредува колку „палци нагоре“ треба да има МР за да може Merge да биде достапна. Вредноста на еден значи дека вие самите можете да го одобрите вашиот MR со тоа што ќе го „лајкнете“.

вклучуваат вклучува тест фаза, која го проверува бројот на „лајкови“.

Наједноставниот цевковод кој го користи 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 во главниот или ослободување /* гранки
  • користејќи го GitLab API, добијте го бројот на „допаѓања“ и „не ми се допаѓаат“
  • пресметајте ја разликата помеѓу позитивните и негативните одговори
  • ако разликата е помала од вредноста што ја поставивме во NEED_VOTES, тогаш ја блокираме можноста за спојување

5. Оневозможи обврзници за заштитени гранки

Ги одредуваме гранките за кои треба да извршиме преглед на кодот и укажуваме дека со нив може да се работи само преку MR.

За да го направите ова, одете во Поставки → Складиште → Заштитени гранки:

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

6. Проверка

Поставете NEED_VOTES: 0

Правиме МР и ставаме „дислајк“.

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

Во дневниците за изградба:

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

Сега ставете „ми се допаѓа“ и проверете повторно:

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

Извор: www.habr.com

Додадете коментар