Jednou z nejpotřebnějších funkcí, která není v bezplatné verzi GitLab, je možnost hlasovat proti vynulování úložiště pro kontrolu žádosti o sloučení (MR) pomocí povinné kontroly kódu.
Minimální funkcionalitu uděláme sami – zakážeme sloučení, dokud několik vývojářů nedá „palec nahoru“ MR.
Proč to vůbec je?
Naše organizace si může dovolit zakoupit licenci GitLab. Ale protože vývoj probíhá v uzavřené smyčce bez přístupu k internetu a existuje přísné plánování rozpočtu, nákup samostatně spravovaných licencí s potřebnou funkčností může trvat mnoho měsíců a musíte pracovat hned.
V důsledku toho musíte:
- nebo některým vývojářům zcela zakázat Merge do chráněných větví, ale pak vývojáři, kteří mají právo na Merge, dostávají jako bonus konflikty při slučování cizích MR;
- nebo vám umožní provádět nekontrolované slučování s vaší hlavní pobočkou bez kontroly kódu, i když je to Junior, který se právě usadil včera.
První, co jsem udělal, bylo googlovat v domnění, že někdo už něco podobného udělal (bez dolaďování kódu), ale ukázalo se, že v komunitní verzi zatím žádná taková implementace není.
Obecné schéma práce
Jako příklad nastavíme schválení žádosti o sloučení na testovacím úložišti :
- Vytvořme si token pro přístup do GitLab API (prostřednictvím něj budeme dostávat informace o počtu hlasů pro a proti)
- Přidejte token do proměnných GitLab
- Zakažte sloučení, pokud se v kanálu vyskytují chyby (pokud není dostatek hlasů „pro“)
- Nastavte ověřování hlasů jako součást kanálu CI/CD
- Zakážeme zavazování chráněných poboček, veškeré změny provádíme pouze prostřednictvím MR
- Podívejme se, co se nakonec stalo
1. Vytvořte token pro přístup k rozhraní API
Přejděte do Nastavení uživatele → Přístupové tokeny a zapište si token:
Účet pro příjem tokenu
Přístup k API vám umožňuje dělat s vašimi repozitáři téměř cokoli, takže vám doporučuji vytvořit samostatný účet Gitlab, dát mu minimální práva ke svým úložištím (jako Reporter) a získat pro tento účet token.
2. Přidejte token do proměnných Gitlabu
Například v předchozím kroku jsme obdrželi token QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Otevřete Nastavení → CI/CD → Proměnné → Přidat proměnnou → GITLAB_TOKEN_FOR_CI
V důsledku toho získáme:
To lze provést jak na jednom úložišti, tak na skupině úložišť.
3. Pokud po přezkoumání kódu neobdržíme souhlas kolegů, zakážeme sloučení
V našem případě bude zákaz Merge spočívat v tom, že montážní potrubí vrátí chybu, pokud nebude dostatek hlasů.
Přejděte do Nastavení → Obecné → Požadavky na sloučení → Kontroly sloučení a povolte možnost Montážní linky musí úspěšně běžet.
4. Nastavte potrubí
Pokud jste pro svou aplikaci ještě nevytvořili kanál CI/CD
Vytvořte soubor v kořenovém adresáři úložiště .gitlab-ci.yml s jednoduchým obsahem:
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žiště pro konfiguraci CI/CD
Doporučil bych vytvořit samostatné úložiště, kde je potřeba vytvořit soubor myapp.gitlab-ci.yml pro nastavení kanálu. Tímto způsobem můžete lépe řídit přístup přispěvatelů, kteří mohou změnit kanál sestavení a získat přístupový token.
Umístění nového souboru potrubí bude nutné zadat tak, že přejdete do úložiště myapp - Nastavení - CI / CD - Montážní řádky - Vlastní konfigurační cesta CI - zadejte nový soubor, například myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Tip: K provádění změn v souborech GitLab CI použijte linter
I když pracujete sami, práce přes MR bude dobrým pomocníkem, který provede všechny vaše změny v souborech kanálu přes linter. Pokud uděláte chybu v syntaxi souboru YAML, neumožní vám to přerušit fungující kanál, ale jednoduše zablokuje Merge.
Příklad kontejnerů s linters, které můžete vložit do svého potrubí:
A příklad fáze ověřování:
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;
Zbývá přidat do kanálu několik parametrů, aby fungoval:
stages:
- test
variables:
NEED_VOTES: 1
include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"
Proměnná NEED_VOTES určuje, kolik "palců nahoru" musí mít MR, aby bylo sloučení dostupné. Hodnota jedna znamená, že vy sami můžete svůj MR schválit tím, že ho „lajknete“.
include zahrnuje testovací fázi, která kontroluje počet "lajků".
Nejjednodušší potrubí používající jako příklad 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/.*$/'
Další informace o tom, co se stane při kontrole:
- je nastaveno omezení, že kontrola bude pouze při vytváření MR ve větvích master nebo release /*
- pomocí GitLab API získejte počet „líbí se“ a „nelíbí se“
- vypočítat rozdíl mezi kladnými a zápornými odpověďmi
- pokud je rozdíl menší než hodnota, kterou jsme nastavili v NEED_VOTES, pak zablokujeme možnost sloučení
5. Deaktivujte commity do chráněných větví
Definujeme pobočky, pro které bychom měli provádět code review, a uvedeme, že s nimi lze pracovat pouze prostřednictvím MR.
Chcete-li to provést, přejděte do Nastavení → Úložiště → Chráněné větve:
6. Kontrola
Nastavit NEED_VOTES: 0
Děláme MR a dáme "nelíbí".
V protokolech sestavení:
Nyní dejte „like“ a spusťte znovu kontrolu:
Zdroj: www.habr.com