Code review in Gitlab CE: als er geen Merge-aanvraaggoedkeuring is, maar ik wil dat echt

Een van de meest benodigde functies die niet in de gratis versie van GitLab zit, is de mogelijkheid om tegen het op nul zetten van de repository te stemmen om het Merge-verzoek (MR) te controleren met behulp van de verplichte codebeoordeling.

We zullen de minimale functionaliteit zelf doen - we zullen Samenvoegen uitschakelen totdat verschillende ontwikkelaars een "duim omhoog" geven aan MR.

Waarom is dit überhaupt?

Onze organisatie kan het zich veroorloven om een ​​GitLab-licentie te kopen. Maar aangezien de ontwikkeling wordt uitgevoerd in een gesloten lus zonder toegang tot internet en er een strikte budgetplanning is, kan de aanschaf van zelfbeheerde licenties met de nodige functionaliteit vele maanden duren en moet u nu werken.

Als gevolg hiervan moet u:

• of verbied Merge in beschermde branches volledig voor sommige ontwikkelaars, maar dan ontvangen ontwikkelaars die het recht hebben om samen te voegen conflicten wanneer ze de MR's van andere mensen samenvoegen als een bonus;
• of laat je ongecontroleerde samenvoegingen doen met je master branch zonder code review, zelfs als het een Junior is die zich gisteren net heeft gevestigd.

Het eerste wat ik deed was googlen, in de overtuiging dat iemand al iets soortgelijks had gedaan (zonder de code te verfijnen), maar het bleek dat een dergelijke implementatie nog niet in de communityversie was.

Algemeen werkschema

Laten we als voorbeeld goedkeuringen voor samenvoegaanvragen instellen op een testrepository mijnapp:

1. Laten we een token maken voor toegang tot de GitLab API (hierdoor ontvangen we informatie over het aantal stemmen voor en tegen)
2. Voeg een token toe aan GitLab-variabelen
3. Schakel Samenvoegen uit als er fouten in de pijplijn zitten (als er niet genoeg 'voor'-stemmen zijn)
4. Stel stemvalidatie in als onderdeel van de CI/CD-pijplijn
5. We zullen het maken van commits naar beschermde branches verbieden, we maken alle wijzigingen alleen via MR
6. Laten we eens kijken wat er uiteindelijk is gebeurd

1. Maak een token aan om toegang te krijgen tot de API

Ga naar Gebruikersinstellingen → Toegangstokens en noteer het token:

Account om het token te ontvangen
Met API-toegang kun je bijna alles doen met je repositories, dus ik raad je aan een apart Gitlab-account aan te maken, minimale rechten te geven aan je repositories (zoals Reporter) en een token voor dat account te krijgen.

2. Voeg het token toe aan Gitlab-variabelen

In de vorige stap hebben we bijvoorbeeld een token ontvangen QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Open Instellingen → CI/CD → Variabelen → Variabele toevoegen → GITLAB_TOKEN_FOR_CI

Als resultaat krijgen we:

Dit kan zowel op één repository als op een groep repositories.

3. We zetten Merge in de ban als de goedkeuring van collega's niet is ontvangen na de code review

In ons geval zal het verbod op Merge zijn dat de assemblagepijplijn een fout zal retourneren als er niet genoeg stemmen zijn.

Ga naar Instellingen → Algemeen → Aanvragen samenvoegen → Controles samenvoegen en schakel de optie Assemblagelijnen moeten succesvol worden uitgevoerd in.

4. Stel de pijplijn in

Als u nog geen CI/CD-pijplijn voor uw toepassing hebt gemaakt
Maak een bestand aan in de root van de repository .gitlab-ci.yml met eenvoudige inhoud:

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"

Afzonderlijke repository voor CI/CD-configuratie
Ik zou aanraden om een ​​aparte repository te maken waar je een myapp.gitlab-ci.yml-bestand moet maken om de pijplijn in te stellen. Op deze manier kunt u de toegang van bijdragers die de build-pijplijn kunnen wijzigen en een toegangstoken kunnen krijgen, beter controleren.

De locatie van het nieuwe pijplijnbestand moet worden opgegeven door naar de myapp-repository te gaan - Instellingen - CI / CD - Assemblagelijnen - Aangepast CI-configuratiepad - geef bijvoorbeeld een nieuw bestand op mijnapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Tip: Gebruik een linter om wijzigingen aan te brengen in GitLab CI-bestanden
Zelfs als u alleen werkt, zal het werken via MR een goede hulp zijn, waarbij al uw wijzigingen aan de pijplijnbestanden via de linter worden uitgevoerd. Als u een fout maakt in de syntaxis van het YAML-bestand, kunt u de werkende pijplijn niet doorbreken, maar gewoon samenvoegen blokkeren.

Een voorbeeld van containers met linters die u in uw pijplijn kunt insluiten:

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

En een voorbeeld van de validatiefase:

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;

Het blijft om een ​​paar parameters aan uw pijplijn toe te voegen om het te laten werken:

stages:
- test

variables:
NEED_VOTES: 1

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

De variabele NEED_VOTES bepaalt hoeveel "thumbs up" MR moet hebben om Samenvoegen beschikbaar te maken. Een waarde van één betekent dat u zelf uw MR kunt goedkeuren door deze te "liken".

include omvat de testfase, die het aantal "likes" controleert.

De eenvoudigste pijplijn met myapp.gitlab-ci.yml als voorbeeld
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

Inhoud van 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/.*$/'


Meer informatie over wat er gebeurt bij het controleren:

• de beperking is ingesteld dat de controle alleen plaatsvindt bij het maken van een MR in de master- of release /*-takken
• gebruik de GitLab API om het aantal "likes" en "dislikes" op te halen
• bereken het verschil tussen positieve en negatieve reacties
• als het verschil kleiner is dan de waarde die we hebben ingesteld in NEED_VOTES, dan blokkeren we de mogelijkheid om samen te voegen

5. Schakel commits naar beschermde branches uit

We bepalen voor welke branches we code review moeten uitvoeren en geven aan dat er alleen mee gewerkt kan worden via MR.

Ga hiervoor naar Instellingen → Repository → Protected Branches:

6. Controleren

NEED_VOTES instellen: 0

We doen MR en zetten een "dislike".

In de buildlogs:

Plaats nu "vind ik leuk" en voer een nieuwe controle uit:

Bron: www.habr.com