🥇Code review a Gitlab CE-ben: ha a Merge request approvals hiányzik, de nagyon szeretnéd

Az egyik legfontosabb funkció, amely hiányzik a GitLab ingyenes verziójából, az a lehetőség, hogy szavazzunk a repó visszaállítása ellen, és irányítsuk a Merge Requestet (MR) kötelező kódellenőrzéssel.

Alapfunkciót fogunk létrehozni: megtiltjuk a Merge-t, amíg több fejlesztő nem nyom egy „tetszik” gombot az MR-en.

Miért van erre egyáltalán szükség?

A szervezetünk megengedheti magának a GitLab licensz megvásárlását. De mivel a fejlesztés zárt körben zajlik, internet hozzáférés nélkül, és a költségvetés szigorú tervezése miatt a szükséges funkcióval rendelkező self-managed licenszek beszerzése hónapokig is eltarthat, miközben már most is dolgoznunk kell.

Végül ezt kell tennünk:

vagy teljesen megtiltjuk a Merge-t a védett ágakban bizonyos fejlesztők számára, de akkor azok a fejlesztők, akik jogosultak a Merge-re, konfliktusokat kapnak, amikor mások MR-jét egyesítik;
vagy lehetőséget adunk a kontroll nélküli egyesítésekre a fő ággal, még akkor is, ha az Junior, aki éppen tegnap állt munkába.

Első lépésben elkezdtem guglizni, feltételezve, hogy biztosan valaki már csinált ilyesmit (kódmódosítás nélkül), de kiderült, hogy ilyen megvalósítás a közösségi verzióban még nem volt.

Az általános működési séma

Példaként beállítjuk a Merge Request jóváhagyásokat egy teszt repozitóriumban myapp:

Hozzunk létre egy tokent a GitLab API eléréséhez (azon keresztül fogjuk kapni az „igen” és „nem” szavazatok számát)
Adjunk hozzá tokent a GitLab változóihoz
Tiltjuk meg a Merge-t a pipeline hibái esetén (ha az „igen” szavazatok száma nem elegendő)
Állítsuk be a szavazatok ellenőrzését a CI/CD pipeline részeként
Tiltjuk a commitokat a védett ágakba, minden módosítást csak MR-en keresztül hajtunk végre
Nézzük meg, hogy mi lett az eredmény

1. Hozzunk létre egy tokent az API eléréséhez

Lépjünk be a Felhasználói beállításokba → Hozzáférési tokének, és jegyezzük meg a tokent:

Fiók a token beszerzéséhez
Az API hozzáférés gyakorlatilag mindent lehetővé tesz a repozitóriumaiddal kapcsolatban, ezért ajánlom, hogy hozz létre egy külön GitLab fiókot, adj neki minimális jogokat a repozitóriumaidra (például Reporter), és szerezz be egy tokent ehhez a fiókhoz.

2. Adjunk hozzá tokent a GitLab változóihoz

Például az előző lépésben megszereztük a tokent QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Nyissuk meg a Beállítások → CI/CD → Változók → Új változó hozzáadása → GITLAB_TOKEN_FOR_CI

Ennek eredményeként kapjuk:

Ez egyetlen tárolón, vagy tárolócsoporton is elvégezhető.

3. Tiltjuk a Merge-t, ha a kollégák jóváhagyása nem érkezett meg a kódellenőrzés után.

Ebben az esetben a Merge tiltása azt jelenti, hogy a build folyamat hibaüzenetet ad vissza, ha nem elegendő szavazat érkezik.

Lépjünk be a Beállítások → Alapértelmezett → Összeolvasztási kérések → Összeolvasztási ellenőrzések menüpontba, és kapcsoljuk be a "A build vonalaknak sikeresen kell futniuk" opciót.

4. Állítsuk be a pipelinet.

Ha még nem készítettél CI/CD folyamatot az alkalmazásodhoz.
Hozzunk létre a tároló gyökerében egy fájlt. .gitlab-ci.yml a legegyszerűbb tartalommal:

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"

Külön tároló a CI/CD konfigurációhoz.
Ajánlom, hogy készíts el egy külön tárolót, ahol létre kell hozni a myapp.gitlab-ci.yml fájlt a pipeline beállításához. Így jobban tudod majd ellenőrizni a résztvevők hozzáférését, akik módosíthatják a build folyamatot és kaphatnak hozzáférési tokent.

Az új pipeline fájl helyét a myapp tárolóban található Beállítások → CI/CD → Build vonalak → CI konfigurációs útvonal beállításával kell megadni – meg kell adni az új fájlt, például: myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Tipp: használj lintet a GitLab CI fájljaiban végzett módosításokhoz.
Még ha egyedül is dolgozol, hasznos lehet, ha MR-en keresztül végzed a munkát, ezzel minden módosítást a pipeline fájljaidban átfuttathatsz a linten. Ha hibát követsz el a YAML fájl szintaxisában, az nem fogja megzavarni a működő pipeline-t, csak megakadályozza a Merge-t.

Példa a linterekkel ellátott konténerekre, amelyeket integrálhatsz a pipelinedbe:

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

És egy példa a tesztelési szakaszra:

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;

Most néhány paramétert kell hozzáadni a pipeline-hoz, hogy minden működjön:

fázis: - teszt

variables:
NEED_VOTES: 1

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

A NEED_VOTES változó határozza meg, hogy hány "lájkra" van szükség a Merge elérhetőségéhez. Egyes érték esetén azt jelenti, hogy te magad is jóváhagyhatod a Merge-t, ha "lájkolod".

Az include csatolja a test szakaszt, amely ellenőrzi a "lájkok" számát.

Egyszerű pipeline példa myapp.gitlab-ci.yml alapján
fázis: - épít - teszt

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
szkript:
- echo CI_MERGE_REQUEST_TARGET_BRANCH_NAME $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
- java HelloWorld.java

A check-approve.gitlab-ci.yml tartalma
ci-mr: színpad: teszt szkript: - 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} Felhasználói szavazat = 1, ellenkező szavazat = -1, MR OK ha szavazatok >=${NEED_VOTES_REAL}" - if [ "${MR_VOTES}" -ge "$(expr ${NEED_VOTES_REAL})" ]; then echo "MR OK"; else echo "MR HIBA További szavazatok szükségesek"; exit 1; fi kép: laptevss\/gitlab-api-util szabályok: - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ \/^release\/.*$\/'

További információ arról, mi történik az ellenőrzés során:

korlátozva lett, hogy ellenőrzés csak a master vagy release/* ágra történő MR létrehozásakor történjen
a GitLab API-t használva megszerezzük a „tetszik” és „nem tetszik” szavazatok számát
kiszámítjuk a pozitív és negatív visszajelzések közötti eltérést
ha az eltérés kisebb, mint a NEED_VOTES által megadott érték, akkor letiltjuk a merge lehetőségét