🥇Code review i Gitlab CE: hvis der ikke er nogen godkendelser af merge request, men man virkelig ønsker det

En af de mest nødvendige funktioner, som ikke findes i den gratis version af GitLab, er muligheden for at stemme imod nulstilling af repositoryet for at kontrollere Merge-anmodningen (MR) ved hjælp af obligatorisk kodegennemgang.

Lad os implementere den minimale funktionalitet selv - vi forbyder Merge, indtil flere udviklere giver "tommel op" til MR.

Hvorfor overhovedet?

Vores organisation kan sagtens tillade sig at købe en licens til GitLab. Men da udviklingen sker i et lukket miljø uden internetadgang, og der er stram budgetplanlægning, kan indkøbet af self-managed licenser med den nødvendige funktionalitet tage mange måneder, og man skal allerede arbejde nu.

Resultatet er, at man bliver nødt til at:

Enten helt forbyde Merge i beskyttede grene for en del udviklere, men så får udviklere, der har ret til Merge, konflikter ved at fusionere andres MR som en bonus;
Eller give mulighed for ukontrollerede fusioner med din master-gren uden kodegennemgang, selvom det er en junior, der lige er startet.

Jeg gik først hen for at google, da jeg troede, at der helt sikkert var nogen, der havde gjort noget lignende (uden kodeændringer), men det viste sig, at en sådan implementering ikke var tilgængelig i community-versionen endnu.

Den overordnede arbejdsplan

Som et eksempel vil vi indstille Merge-anmodningsgodkendelser på et test-repository myapp:

Lad os oprette en token for adgang til GitLab API (gennem den vil vi modtage information om antallet af stemmer "for" og "imod")
Tilføj tokenet til GitLab-variabler
Forbyd Merge ved fejl i pipeline (hvis der ikke er tilstrækkeligt antal stemmer "for")
Indstil stemmekontrollen som en del af CI/CD-pipelinen
Forbyd at lave commits i beskyttede grene, alle ændringer foretages kun gennem MR
Lad os tjekke, hvad resultatet blev

1. Opretter en token for adgang til API'en

Gå til Brugerindstillinger → Adgangs Tokens og skriv tokenet ned:

Kontoen til at modtage token
Adgang til API'en giver mulighed for at gøre næsten alt med dine repositories, så jeg anbefaler at oprette en separat GitLab-konto, give den minimale rettigheder til dine repositories (for eksempel Reporter) og få tokenet til denne konto.

2. Tilføj tokenet til GitLab-variabler

For eksempel fik vi tokenet på det foregående trin QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Åbn Indstillinger → CI/CD → Variabler → Tilføj variabel → GITLAB_TOKEN_FOR_CI

Vi ender op med:

Dette kan gøres enten på et enkelt repository eller i en gruppe af repositories.

3. Forbyd Merge, hvis der ikke er indhentet godkendelser fra kolleger efter udført code review

I vores tilfælde vil forbuddet mod Merge være, at build-pipelinen returnerer en fejl ved utilstrækkeligt antal stemmer.

Gå til Indstillinger → Generelt → Fusionsanmodninger → Fusionskontrol og aktiver indstillingen, at build-linjer skal køres med succes.

4. Konfigurer pipelinen

Hvis du ikke allerede har lavet en CI/CD-pipeline til din applikation
Opret en fil i rodmappen på repository'et .gitlab-ci.yml med det enkleste indhold:

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"

Et særskilt repository til CI/CD-konfiguration
Jeg ville anbefale at lave et særskilt repository, hvor du skal oprette filen myapp.gitlab-ci.yml til at konfigurere pipelinen. På den måde kan du bedre kontrollere adgangen for deltagere, der kan ændre build-pipelinen og få adgangstoken.

Placeringen af den nye pipeline-fil skal angives ved at gå ind i repository'et myapp – Indstillinger – CI/CD – Build-linjer – Brugerdefineret CI-konfigurationsvej – angive den nye fil, fx myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Tip: Brug en linter til at ændre filer i GitLab CI
Selv hvis du arbejder alene, kan det være en god hjælp at arbejde gennem MR, ved at køre alle de ændringer, du har lavet i pipeline-filerne, gennem en linter. Hvis du laver en fejl i syntaksen i YAML-filen, vil det ikke bryde din arbejds-pipeline, men blot blokere Merge.

Eksempel på containere med linters, som du kan integrere i din pipeline:

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

Og et eksempel på en kontrolfase:

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 er nu tid til at tilføje nogle parametre til din pipeline, så alt fungerer:

faser: - test

variables:
NEED_VOTES: 1

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

Variablen NEED_VOTES definerer, hvor mange "thumbs up" MR'en skal have, for at Merge er tilgængeligt. En værdi på én betyder, at du selv kan godkende din MR ved at "like" det.

include tilføjer testfasen, der kontrollerer antallet af "likes".

Den enkleste pipeline med eksemplet myapp.gitlab-ci.yml
faser: - byg - 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

Indhold af check-approve.gitlab-ci.yml
ci-mr: fase: 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})" ]; så echo "MR OK"; ellers echo "MR FEJL Need more votes"; exit 1; fi billede: laptevss/gitlab-api-util regler: - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^release/.*$/ '

Mere om hvad der sker under godkendelsen:

der er indført en begrænsning, at godkendelsen kun vil finde sted ved oprettelse af MR i grene master eller release/*
ved at bruge GitLab API, får vi antallet af "likes" og "dislikes"
vi beregner forskellen mellem positive og negative tilbagemeldinger
hvis forskellen er mindre end den værdi, vi har angivet i NEED_VOTES, blokerer vi muligheden for at lave en sammenlægning