Kodgranskning i Gitlab CE: om det inte finns några godkännanden av Merge-begäran, men jag vill verkligen

En av de mest nödvändiga funktionerna, som inte finns i den fria versionen av GitLab, är möjligheten att rösta mot repository nullification och control Merge request (MR), med den obligatoriska kodgranskningen.

Låt oss göra minimifunktionaliteten själva - vi kommer att förbjuda Merge tills flera utvecklare ger MR en tumme upp.

Varför är detta ens nödvändigt?

Vår organisation har lätt råd att köpa en GitLab-licens. Men eftersom utvecklingen sker i en sluten slinga utan tillgång till internet, och det finns strikt budgetplanering, kan köpet av egenhanterade licenser med nödvändig funktionalitet dra ut på tiden i många månader, men arbetet måste göras nu.

Som ett resultat måste du:

• eller helt förbjuda Merge i skyddade filialer för vissa utvecklare, men då får utvecklare som har rätt att Merge konflikter när de slår samman andras MR:er som en bonus;
• eller ge möjlighet att göra okontrollerade sammanslagningar med din mastergren utan kodgranskning, även om det är Junior, som anställdes igår.

Det första jag gjorde var att Google, och trodde att någon definitivt redan hade gjort något liknande (utan att ändra koden), men det visade sig att det inte fanns någon sådan implementering i communityversionen ännu.

Allmänt arbetsschema

Som ett exempel, låt oss konfigurera godkännanden av sammanslagningsförfrågningar på ett testlager minapp:

1. Låt oss 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åt oss lägga till token till GitLab-variablerna
3. Låt oss inaktivera Merge i händelse av fel i pipelinen (om det inte finns tillräckligt med uppröster)
4. Låt oss ställa in röstverifiering som en del av CI/CD-pipeline
5. Vi förbjuder att göra åtaganden till skyddade filialer; alla ändringar görs endast genom MR
6. Låt oss kolla vad som hände till slut

1. Skapa en token för att komma åt API:t

Gå till Användarinställningar → Access Tokens och skriv ned token:

Konto för att få en token
API-åtkomst låter dig göra nästan vad som helst med dina arkiv, så jag rekommenderar att du skapar ett separat Gitlab-konto, ger det minimala rättigheter till dina arkiv (t.ex. Reporter) och får en token för det kontot.

2. Lägg till token till Gitlab-variablerna

Till exempel, i föregående steg fick vi en token QmN2Y0NOUFlfeXhvd21ZS01aQzgK

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

Som ett resultat får vi:

Detta kan göras antingen på ett arkiv eller på en grupp av arkiv.

3. Vi sätter ett förbud mot Merge om godkännande av kollegor inte erhålls efter kodgranskning.

I vårt fall kommer förbudet mot Merge att vara att monteringsledningen kommer att returnera ett fel om det inte finns tillräckligt med röster.

Gå till Inställningar → Allmänt → Merge Requests → Merge Checks och aktivera alternativet Monteringslinjer måste slutföras framgångsrikt.

4. Installation av pipeline

Om du ännu inte har skapat en CI/CD-pipeline för din applikation
Skapa en fil i roten av förvaret .gitlab-ci.yml med det enklaste innehållet:

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"

Separat arkiv för CI/CD-konfiguration
Jag skulle rekommendera att skapa ett separat arkiv där du måste skapa en myapp.gitlab-ci.yml-fil för att konfigurera pipelinen. På så sätt kan du bättre kontrollera åtkomsten för deltagare som kan ändra byggpipeline och få en åtkomsttoken.

Platsen för den nya pipeline-filen måste specificeras genom att gå till myapp-arkivet - Inställningar - CI/CD - Monteringslinjer - Anpassad CI-konfigurationssökväg - ange den nya filen, t.ex. 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, kommer det att vara en bra hjälp att arbeta genom MR, att köra alla dina ändringar av pipelinefiler genom en linter. Om du gör ett misstag i syntaxen för YAML-filen kommer den inte att bryta din produktionspipeline, utan blockerar helt enkelt Merge.

Ett exempel på behållare med linters som du kan bygga in i din pipeline:

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

Och ett exempel på verifieringsstadiet:

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 till din pipeline för att få det att fungera:

stages:
- 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 bestämmer hur många "tummen upp" MR måste ha för att Merge ska vara tillgänglig. Ett värde lika med ett betyder att du själv kan godkänna din MR genom att "gilla" den.

inkluderar teststadiet, som kontrollerar antalet "gilla".

Den enklaste pipelinen med exemplet 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

Innehåll 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/.*$/'


Mer information om vad som händer under verifieringen:

• det finns en begränsning att kontrollen endast kommer att göras när MR skapas i master- eller release/*-grenarna
• med GitLab API får vi antalet "gillar" och "ogillar"
• beräkna skillnaden mellan positiva och negativa svar
• om skillnaden är mindre än värdet vi anger i NEED_VOTES, blockerar vi möjligheten att slå samman

5. Förbjud begås till skyddade grenar

Vi definierar för vilka grenar vi ska genomföra kodgranskningar och anger att de endast kan arbetas med genom MR.

För att göra detta, gå till Inställningar → Förvar → Skyddade grenar:

6. Kontrollera

Ställ in NEED_VOTES: 0

Vi gör en MR och sätter en "ogilla".

I byggloggarna:

Lägg nu "gilla" och börja kolla igen:

Källa: will.com