ProHoster > Blog > Adminisztráció > Kód felülvizsgálata a Gitlab CE-ben: ha nincs összevonási kérelem jóváhagyása, de nagyon szeretném

Kód felülvizsgálata a Gitlab CE-ben: ha nincs összevonási kérelem jóváhagyása, de nagyon szeretném

Kód felülvizsgálata a Gitlab CE-ben: ha nincs összevonási kérelem jóváhagyása, de nagyon szeretném

Az egyik legszükségesebb szolgáltatás, amely nem szerepel a GitLab ingyenes verziójában, az a képesség, hogy a lerakat nullázása ellen szavazzunk, hogy az összevonási kérelmet (MR) a kötelező kódellenőrzés segítségével vezérelhessük.

A minimális funkcionalitást magunk végezzük el – letiltjuk a Merge funkciót mindaddig, amíg több fejlesztő fel nem tartja az MR-t.

Miért van ez egyáltalán?

Szervezetünk megengedheti magának, hogy GitLab licencet vásároljon. De mivel a fejlesztés zárt körben, internet-hozzáférés nélkül zajlik, és szigorú költségvetési tervezés van, a szükséges funkcionalitással rendelkező, önállóan kezelt licencek beszerzése több hónapig is eltarthat, és most dolgozni kell.

Ennek eredményeként a következőket kell tennie:

  • vagy teljesen megtiltja egyes fejlesztők számára a Merge-t védett ágakba, de ilyenkor azok a fejlesztők, akiknek joguk van egyesíteni, ütközéseket kapnak, amikor mások MR-eit egyesítik bónuszként;
  • vagy lehetővé teszi, hogy ellenőrizetlen összevonásokat hajtson végre a fő ággal a kód áttekintése nélkül, még akkor is, ha egy Juniorról van szó, aki éppen tegnap telepedett le.

Az első dolgom volt, hogy rákerestem a google-ra, mert azt hittem, hogy valaki már csinált hasonlót (a kód finomítása nélkül), de kiderült, hogy a közösségi verzióban még nincs ilyen megvalósítás.

Általános munkaséma

Példaként állítsuk be az összevonási kérelmek jóváhagyását egy teszttárban myapp:

  1. Készítsünk egy tokent a GitLab API eléréséhez (rajta keresztül kapunk információt a pro és a kontra szavazatok számáról)
  2. Adjon hozzá egy tokent a GitLab-változókhoz
  3. Kapcsolja ki az Egyesítést, ha hibák vannak a folyamatban (ha nincs elég „mellette” szavazat)
  4. Szavazatérvényesítés beállítása a CI/CD folyamat részeként
  5. A védett ágakra vonatkozó kötelezettségvállalást megtiltjuk, minden változtatást csak az MR-en keresztül hajtunk végre
  6. Nézzük meg, mi történt a végén

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

Nyissa meg a Felhasználói beállítások → Hozzáférési tokenek menüpontot, és írja le a tokent:

Kód felülvizsgálata a Gitlab CE-ben: ha nincs összevonási kérelem jóváhagyása, de nagyon szeretném

Fiók a token fogadásához
Az API-hozzáféréssel szinte bármit megtehetsz a tárolóiddal, ezért azt javaslom, hogy hozz létre egy külön Gitlab-fiókot, adj neki minimális jogokat a tárolóidhoz (például a Reporterhez), és szerezz be egy tokent a fiókhoz.

2. Adja hozzá a tokent a Gitlab változókhoz

Például az előző lépésben kaptunk egy tokent QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Nyissa meg a Beállítások → CI/CD → Változók → Változó hozzáadása → lehetőséget GITLAB_TOKEN_FOR_CI

Kód felülvizsgálata a Gitlab CE-ben: ha nincs összevonási kérelem jóváhagyása, de nagyon szeretném

Ennek eredményeként a következőket kapjuk:

Kód felülvizsgálata a Gitlab CE-ben: ha nincs összevonási kérelem jóváhagyása, de nagyon szeretném

Ez egy lerakaton és lerakatcsoporton is megtehető.

3. Betiltjuk a Merge-et, ha a kód áttekintése után nem érkezik meg a kollégák jóváhagyása

Esetünkben a Merge tiltása az lesz, hogy az assembly pipeline hibát ad vissza, ha nincs elég szavazat.

Lépjen a Beállítások → Általános → Egyesítési kérelmek → Egyesítési ellenőrzések menüpontra, és engedélyezze az Összeállítási vonalaknak sikeresen futniuk kell opciót.

Kód felülvizsgálata a Gitlab CE-ben: ha nincs összevonási kérelem jóváhagyása, de nagyon szeretném

4. Állítsa be a csővezetéket

Ha még nem készített CI/CD folyamatot az alkalmazásához
Hozzon létre egy fájlt a tároló gyökerében .gitlab-ci.yml egyszerű 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
Azt javaslom, hogy készítsen egy külön tárolót, ahol létre kell hoznia egy myapp.gitlab-ci.yml fájlt a folyamat beállításához. Így jobban szabályozhatja azon közreműködők hozzáférését, akik módosíthatják az összeállítási folyamatot, és hozzáférési jogkivonatot kaphatnak.

Az új folyamatfájl helyét meg kell adni a myapp tárolójában - Beállítások - CI / CD - Összeszerelő sorok - Egyéni CI konfigurációs útvonal - adjon meg egy új fájlt, pl. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Tipp: Használjon lintert a GitLab CI-fájlok módosításához
Még akkor is, ha egyedül dolgozik, az MR-en keresztüli munka jó segítőtárs lesz, mivel a csővezeték-fájlok minden módosítását a linteren keresztül futtatja. Ha hibát vét a YAML fájl szintaxisában, ez nem teszi lehetővé a működő folyamat megszakítását, hanem egyszerűen blokkolja az összevonást.

Példa a csővezetékbe beágyazható linterekkel ellátott tárolókra:

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

És egy példa az érvényesíté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;

A működéshez hozzá kell adni néhány paramétert a folyamathoz:

stages:
- test

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 az MR-nek hány „tetszik”-nek kell lennie ahhoz, hogy a Merge elérhető legyen. Az egy érték azt jelenti, hogy te magad is jóváhagyhatod az MR-edet, ha „lájkolod”.

include tartalmazza a teszt szakaszt, amely ellenőrzi a "lájkok" számát.

A legegyszerűbb folyamat a myapp.gitlab-ci.yml használatával példaként
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

A check-approve.gitlab-ci.yml tartalma
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/.*$/'

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

  • a korlátozás be van állítva, hogy az ellenőrzés csak akkor lesz, ha MR-t hoz létre a master vagy a release /* ágban
  • a GitLab API használatával kapja meg a "tetszik" és a "nem tetszik" számot
  • Számítsa ki a pozitív és negatív válaszok közötti különbséget
  • ha a különbség kisebb, mint a NEED_VOTES-ban beállított érték, akkor blokkoljuk az összevonás lehetőségét

5. Tiltsa le a védett ágakra vonatkozó véglegesítést

Meghatározzuk azokat az ágakat, amelyekre vonatkozóan kódellenőrzést kell végeznünk, és jelezzük, hogy ezekkel csak MR-en keresztül lehet dolgozni.

Ehhez lépjen a Beállítások → Tárhely → Védett ágak menüpontba:

Kód felülvizsgálata a Gitlab CE-ben: ha nincs összevonási kérelem jóváhagyása, de nagyon szeretném

6. Ellenőrzés

NEED_VOTES beállítása: 0

Csinálunk MR-t és teszünk egy "nem tetszik".

Kód felülvizsgálata a Gitlab CE-ben: ha nincs összevonási kérelem jóváhagyása, de nagyon szeretném

Az építési naplókban:

Kód felülvizsgálata a Gitlab CE-ben: ha nincs összevonási kérelem jóváhagyása, de nagyon szeretném

Most nyomd meg a "tetszik"-t, és ellenőrizd újra:

Kód felülvizsgálata a Gitlab CE-ben: ha nincs összevonási kérelem jóváhagyása, de nagyon szeretném

Forrás: will.com

Hozzászólás