Kontrola kódu v Gitlab CE: ak neexistujú žiadne schválenia žiadosti o zlúčenie, ale naozaj chcem

Jednou z najpotrebnejších funkcií, ktorá nie je v bezplatnej verzii GitLab, je možnosť hlasovať proti zrušeniu úložiska a kontrolovať žiadosť o zlúčenie (MR) pomocou povinného preskúmania kódu.

Urobme si minimálnu funkcionalitu sami – zakážeme Merge, kým viacerí vývojári nedajú MR palec hore.

Prečo je to vôbec potrebné?

Naša organizácia si môže ľahko dovoliť kúpiť licenciu GitLab. Keďže sa však vývoj uskutočňuje v uzavretej slučke bez prístupu na internet a existuje prísne plánovanie rozpočtu, nákup samostatne spravovaných licencií s potrebnou funkcionalitou sa môže natiahnuť na mnoho mesiacov, ale teraz je potrebné pracovať.

V dôsledku toho musíte:

• alebo úplne zakázať Merge v chránených vetvách pre niektorých vývojárov, ale potom vývojári, ktorí majú právo na Merge, dostávajú konflikty pri zlučovaní MR iných ľudí ako bonus;
• alebo dať príležitosť na nekontrolované zlúčenie s vašou hlavnou pobočkou bez kontroly kódu, aj keď je to Junior, ktorý bol prijatý práve včera.

Ako prvé som urobil Google v domnení, že niečo podobné už niekto určite urobil (bez úpravy kódu), no ukázalo sa, že v komunitnej verzii zatiaľ takáto implementácia neexistuje.

Všeobecná schéma práce

Ako príklad nakonfigurujme schválenia žiadostí o zlúčenie v testovacom archíve moja aplikácia:

1. Vytvorme si token pre prístup do GitLab API (prostredníctvom neho budeme dostávať informácie o počte hlasov „za“ a „proti“)
2. Pridajme token do premenných GitLab
3. Zakážme zlúčenie v prípade chýb v potrubí (ak nie je dostatok hlasov za)
4. Nastavme overovanie hlasov ako súčasť CI/CD potrubia
5. Zakazujeme robiť záväzky voči chráneným pobočkám, všetky zmeny sú vykonávané iba prostredníctvom MR
6. Pozrime sa, čo sa nakoniec stalo

1. Vytvorte token na prístup k API

Prejdite do Nastavenia používateľa → Prístupové tokeny a zapíšte si token:

Účet na získanie tokenu
API prístup vám umožňuje robiť s vašimi úložiskami takmer čokoľvek, preto odporúčam vytvoriť si samostatný účet Gitlab, dať mu minimálne práva na vaše úložiská (napr. Reporter) a získať pre tento účet token.

2. Pridajte token do premenných Gitlabu

Napríklad v predchádzajúcom kroku sme dostali token QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Otvorte Nastavenia → CI/CD → Premenné → Pridať premennú → GITLAB_TOKEN_FOR_CI

V dôsledku toho dostaneme:

Dá sa to urobiť buď na jednom úložisku alebo na skupine úložisk.

3. Zakázali sme zlúčenie, ak po preskúmaní kódu nedostanete súhlas kolegov.

V našom prípade bude zákaz Zlúčiť, že montážne potrubie vráti chybu, ak nebude dostatok hlasov.

Prejdite do Nastavenia → Všeobecné → Požiadavky na zlúčenie → Kontroly na zlúčenie a povoľte možnosť Montážne linky sa musia úspešne dokončiť.

4. Nastavenie potrubia

Ak ste ešte nevytvorili kanál CI/CD pre vašu aplikáciu
Vytvorte súbor v koreňovom adresári úložiska .gitlab-ci.yml s najjednoduchším obsahom:

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"

Samostatné úložisko pre konfiguráciu CI/CD
Odporúčal by som vytvoriť samostatné úložisko, v ktorom musíte vytvoriť súbor myapp.gitlab-ci.yml na konfiguráciu potrubia. Týmto spôsobom môžete lepšie kontrolovať prístup účastníkov, ktorí môžu zmeniť kanál zostavovania a získať prístupový token.

Umiestnenie nového súboru potrubia bude potrebné špecifikovať tak, že prejdete do úložiska myapp - Nastavenia - CI/CD - Montážne linky - Vlastná konfiguračná cesta CI - zadajte nový súbor, napr. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Tip: Na vykonanie zmien v súboroch GitLab CI použite linter
Dokonca aj keď pracujete sami, práca cez MR bude dobrou pomôckou, pretože všetky vaše zmeny v súboroch potrubia spustíte cez linter. Ak urobíte chybu v syntaxi súboru YAML, nenaruší to váš produkčný kanál, ale jednoducho zablokuje zlúčenie.

Príklad kontajnerov s vložkami, ktoré môžete zabudovať do svojho potrubia:

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

A príklad fázy overovania:

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;

Zostáva pridať niekoľko parametrov do vášho potrubia, aby to fungovalo:

stages:
- test

variables:
NEED_VOTES: 1

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

Premenná NEED_VOTES určuje, koľko „palcov hore“ musí mať MR, aby bolo zlúčenie dostupné. Hodnota rovnajúca sa jednej znamená, že vy sami môžete schváliť svoju MR tým, že sa jej „páči“.

obsahuje testovaciu fázu, ktorá kontroluje počet „páči sa mi“.

Najjednoduchšie potrubie na príklade 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

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


Ďalšie informácie o tom, čo sa stane počas overovania:

• existuje obmedzenie, že kontrola bude vykonaná len pri vytváraní MR vo vetvách master alebo release/*
• pomocou GitLab API získame počet „páči sa mi“ a „nepáči sa mi“
• vypočítajte rozdiel medzi pozitívnymi a negatívnymi odpoveďami
• ak je rozdiel menší ako hodnota, ktorú sme nastavili v NEED_VOTES, potom zablokujeme možnosť zlúčenia

5. Zakázať zaväzuje chránené pobočky

Definujeme pobočky, pre ktoré musíme vykonávať kontroly kódu, a uvádzame, že s nimi možno pracovať iba prostredníctvom MR.

Ak to chcete urobiť, prejdite do časti Nastavenia → Úložisko → Chránené pobočky:

6. Skontrolujte

Nastaviť NEED_VOTES: 0

Urobíme MR a dáme „nepáči sa mi“.

V denníkoch zostavy:

Teraz dajte „páči sa mi“ a začnite znova kontrolovať:

Zdroj: hab.com