En af de mest nødvendige funktioner, der ikke er i den gratis version af GitLab, er muligheden for at stemme imod nulstilling af lageret for at kontrollere Merge request (MR) ved hjælp af den obligatoriske kodegennemgang.
Vi vil selv udføre minimumsfunktionaliteten - vi deaktiverer Merge, indtil flere udviklere giver en "thumbs up" til MR.
Hvorfor er dette overhovedet?
Vores organisation har råd til at købe en GitLab-licens. Men da udviklingen foregår i et lukket kredsløb uden adgang til internettet, og der er en stram budgetplanlægning, kan køb af selvadministrerede licenser med den nødvendige funktionalitet tage mange måneder, og du skal arbejde nu.
Som et resultat skal du:
- eller fuldstændigt forbyde Merge til beskyttede filialer for nogle udviklere, men så modtager udviklere, der har ret til Merge, konflikter, når de fusionerer andres MR'er som en bonus;
- eller tillade dig at lave ukontrollerede fusioner med din mastergren uden kodegennemgang, selvom det er en Junior, der lige slog sig ned i går.
Det første, jeg gjorde, var at gå på google og tro, at nogen allerede havde gjort noget lignende (uden at forfine koden), men det viste sig, at der ikke var en sådan implementering i fællesskabsversionen endnu.
Generel arbejdsplan
Lad os som et eksempel opsætte fletanmodningsgodkendelser på et testlager :
- Lad os oprette et token for at få adgang til GitLab API (gennem det vil vi modtage information om antallet af stemmer for og imod)
- Tilføj et token til GitLab-variabler
- Deaktiver fletning, hvis der er fejl i pipelinen (hvis der ikke er nok "til" stemmer)
- Opsæt stemmevalidering som en del af CI/CD-pipeline
- Vi vil forbyde at forpligte sig til beskyttede filialer, vi foretager kun alle ændringer gennem MR
- Lad os tjekke, hvad der skete til sidst
1. Opret et token for at få adgang til API'en
Gå til Brugerindstillinger → Adgangstokens og skriv tokenet ned:
Konto for at modtage tokenet
API-adgang giver dig mulighed for at gøre næsten hvad som helst med dine repositories, så jeg foreslår, at du opretter en separat Gitlab-konto, giver den minimale rettigheder til dine repositories (som Reporter) og får et token til den konto.
2. Tilføj token til Gitlab-variabler
For eksempel modtog vi et token i det foregående trin QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Åbn Indstillinger → CI/CD → Variabler → Tilføj variabel → GITLAB_TOKEN_FOR_CI
Som et resultat får vi:
Dette kan gøres både på ét depot og på en gruppe af depoter.
3. Vi sætter et forbud mod Merge, hvis godkendelse af kollegaer ikke modtages efter kodegennemgangen
I vores tilfælde vil forbuddet mod Merge være, at samlerøret vil returnere en fejl, hvis der ikke er stemmer nok.
Gå til Indstillinger → Generelt → Fletanmodninger → Flettjek, og aktiver indstillingen Samlebånd skal køre med succes.
4. Sæt rørledningen op
Hvis du endnu ikke har lavet en CI/CD-pipeline til din ansøgning
Opret en fil i roden af depotet .gitlab-ci.yml med enkelt 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"
Separat lager til CI/CD-konfiguration
Jeg vil anbefale at lave et separat lager, hvor du skal oprette en myapp.gitlab-ci.yml fil for at opsætte pipelinen. På denne måde kan du bedre kontrollere adgangen for bidragydere, som kan ændre build-pipeline og få et adgangstoken.
Placeringen af den nye pipeline-fil skal angives ved at gå til myapp-lageret - Indstillinger - CI / CD - Samlelinjer - Brugerdefineret CI-konfigurationssti - angiv en ny fil, f.eks. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Tip: Brug en linter til at foretage ændringer i GitLab CI-filer
Selvom du arbejder alene, vil det at arbejde gennem MR være en god hjælper, da du kører alle dine ændringer af pipeline-filerne gennem linteren. Hvis du laver en fejl i syntaksen for YAML-filen, vil dette ikke tillade dig at bryde arbejdspipelinen, men vil blot blokere Merge.
Et eksempel på beholdere med linters, som du kan integrere i din pipeline:
Og et eksempel på valideringsstadiet:
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 tilbage at tilføje et par parametre til din pipeline for at få det til at fungere:
stages:
- 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 bestemmer, hvor mange "thumbs up" MR skal have, for at Merge er tilgængelig. En værdi på én betyder, at du selv kan godkende din MR ved at "like" den.
inkludere inkluderer teststadiet, som kontrollerer antallet af "likes".
Den enkleste pipeline med myapp.gitlab-ci.yml som eksempel
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
Indholdet af 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/.*$/'
Få mere at vide om, hvad der sker, når du tjekker:
- begrænsningen er sat til, at kontrollen kun vil være ved oprettelse af en MR i master- eller release /*-grenene
- ved hjælp af GitLab API, få antallet af "likes" og "dislikes"
- beregne forskellen mellem positive og negative svar
- hvis forskellen er mindre end den værdi, vi indstillede i NEED_VOTES, blokerer vi muligheden for at flette
5. Deaktiver commits til beskyttede filialer
Vi bestemmer de brancher, som vi skal gennemføre kodegennemgang for, og angiver, at de kun kan arbejdes med gennem MR.
For at gøre dette skal du gå til Indstillinger → Lager → Beskyttede grene:
6. Kontrol
Indstil NEED_VOTES: 0
Vi laver MR og sætter et "dislike".
I byggelogfilerne:
Sæt nu "synes godt om" og kør en gencheck:
Kilde: www.habr.com