Kodgranskning i GitLab CE: om det inte finns några godkännanden för merge-förfrågningar, men man verkligen vill ha det

En av de mest efterfrågade funktionerna, som saknas i den kostnadsfria versionen av GitLab, är möjligheten att rösta emot att återställa ett repository och kontrollera merge-förfrågningar (MR) med hjälp av obligatorisk kodgranskning.

Vi ska skapa minimal funktionalitet själva - förbjuda merge tills flera utvecklare har gett "tummen upp" på MR.

Varför behövs detta överhuvudtaget?

Vår organisation kan absolut ha råd med en licens för GitLab. Men eftersom utvecklingen sker i en sluten miljö utan internetåtkomst, och det finns strikt budgetplanering, kan anskaffningen av self-managed licenser med nödvändig funktionalitet dra ut på tiden i flera månader, medan vi redan måste arbeta nu.

Resultatet blir att vi:

• antingen helt förbjuder merges i skyddade grenar för vissa utvecklare, men då får utvecklare som har rätt att merge konflikter vid sammanslagning av andras MR som en bonus;
• eller så ger vi möjlighet till okontrollerade sammanslagningar med din mastergren utan kodgranskning, även om det är en Junior som anställdes just igår.

Först och främst började jag googla och trodde att någon helt säkert hade gjort något liknande tidigare (utan kodändringar), men det visade sig att en sådan implementation ännu inte funnits i community-versionen.

Allmän arbetsprocess

Som exempel ska vi ställa in godkännanden av merge-förfrågningar på ett testrepository myapp:

1. Skapa en token för åtkomst till GitLab API (genom den kommer vi att få information om antalet röster "för" och "emot")
2. Lägg till token i GitLab-variabler
3. Förbjud merge vid fel i pipelinen (om antalet röster "för" är otillräckligt)
4. Ställ in röstkontroll som en del av CI/CD-pipelinen
5. Förbjud att göra commits i skyddade grenar, alla ändringar görs endast genom MR
6. Kontrollera vad vi har uppnått

1. Skapa en token för åtkomst till API

Gå till Användarinställningar → Åtkomsttokens och notera token:

Ett konto för att få token
Åtkomst till API gör att du kan göra nästan vad som helst med dina repositories, så jag rekommenderar att du skapar ett separat GitLab-konto, ger det minimiåtkomster till dina repositories (till exempel Reporter) och får en token för detta konto.

2. Lägg till token i GitLab-variabler

Till exempel, på det föregående steget fick vi token QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Öppna Inställningar → CI/CD → Variabler → Lägg till variabel → GITLAB_TOKEN_FOR_CI

$$display$$F(phi)=|y|^2=frac{sin^2(pi frac{Nd}{lambda}sinphi)}{sin^2(pi frac{d}{lambda}sinphi)} $$display$$

Detta kan göras antingen på ett enskilt repository eller på en grupp av repositories.

3. Sätt ett förbud mot Merge om kollegors godkännanden inte får in efter genomfört code review.

I vårt fall kommer förbudet mot Merge att vara att byggkonveyorn returnerar ett fel vid otillräckligt antal röster.

Gå till Inställningar → Grundläggande → Merge-förfrågningar → Merge-kontroller och aktivera alternativet Bygglinjer måste köras framgångsrikt.

4. Ställ in pipelinen

Om du ännu inte har skapat en CI/CD konveyor för din applikation
Skapa en fil i roten av repositoryt .gitlab-ci.yml med enklast möjliga innehåll:

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"

Ett separat repository för CI/CD-konfiguration
Jag skulle rekommendera att skapa ett separat repository där du måste skapa en fil myapp.gitlab-ci.yml för att ställa in pipelinen. På så sätt kan du bättre kontrollera åtkomsten för deltagarna som kan ändra byggpipen och få åtkomsttoken.

Platsen för den nya pipelinfilen måste anges genom att gå till repositoryt myapp — Inställningar — CI/CD — Bygglinjer — Användarspecifik CI-konfigurationsväg — ange den nya filen, till exempel myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Tips: Använd en linter för att göra ändringar i GitLab CI-filer.
Även om du arbetar ensam kan det vara en bra hjälp att arbeta genom MR, och köra alla dina filändringar genom en linter. Om du gör ett misstag i YAML-filens syntax kommer det inte att bryta den fungerande pipelinen utan helt enkelt blockera Merge.

Exempel på behållare med linters som du kan integrera i din pipeline:

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

Och ett exempel på en verifieringssteg:

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;

Det återstår att lägga till några parametrar i din pipeline så att allt fungerar:

steg:
- test

variables:
NEED_VOTES: 1

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

Variabeln NEED_VOTES definierar hur många "tumme upp" som måste finnas för MR för att Merge ska vara tillgängligt. Ett värde av en betyder att du själv kan godkänna din MR genom att "gilla" den.

include kopplar teststeget som kontrollerar antalet "gilla".

Enkel pipeline med exemplet myapp.gitlab-ci.yml
steg:
- bygg
- 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

Innehåll check-approve.gitlab-ci.yml
ci-mr:
steg: 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} Upp röst = 1, ner röst = -1, MR OK om röster >=${NEED_VOTES_REAL}"
- if [ "${MR_VOTES}" -ge "$(expr ${NEED_VOTES_REAL})" ];
then
echo "MR OK";
else
echo "MR FEL Behöver fler röster";
exit 1;
fi
bild: laptevss/gitlab-api-util
regler:
- if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ \/^release\/.*$\/'


Mer om vad som händer vid granskning:

• ett villkor har satts så att granskning endast sker vid skapande av MR till brancherna master eller release/*
• använder GitLab API för att hämta antal 'likes' och 'dislikes'
• beräknar skillnaden mellan positiva och negativa röster
• om skillnaden är lägre än det värde vi angivit i NEED_VOTES, blockeras möjligheten att göra sammanslagningar

5. Förbjuder commits i skyddade brancher

Definierar brancher för vilka vi måste genomföra code review och anger att arbete med dem endast är möjligt via MR.

För detta besöker vi Inställningar → Repository → Protected Branches:

6. Kontrollerar

Sätter NEED_VOTES: 0

Gör en MR och sätter 'dislike'.

I byggloggarna:

Nu sätter vi 'like' och kör en ny kontroll:

Källa: habr.com