En av de mest nødvendige funksjonene som ikke er i gratisversjonen av GitLab, er muligheten til å stemme mot nullstilling av depotet for å kontrollere sammenslåingsforespørselen (MR) ved å bruke den obligatoriske kodegjennomgangen.
Vi vil gjøre minimumsfunksjonaliteten selv - vi vil deaktivere Merge til flere utviklere gir en "tommel opp" til MR.
Hvorfor er dette i det hele tatt?
Vår organisasjon har råd til å kjøpe en GitLab-lisens. Men siden utviklingen utføres i en lukket sløyfe uten tilgang til Internett, og det er en streng budsjettplanlegging, kan kjøp av selvstyrte lisenser med nødvendig funksjonalitet ta mange måneder, og du må jobbe nå.
Som et resultat må du:
- eller fullstendig forby flette inn i beskyttede grener for noen utviklere, men utviklere som har rett til å slå sammen mottar konflikter når de slår sammen andres MR-er som en bonus;
- eller tillate deg å gjøre ukontrollerte fusjoner med mastergrenen din uten kodegjennomgang, selv om det er en junior som nettopp slo seg ned i går.
Det første jeg gjorde var å gå på google, og tro at noen allerede hadde gjort noe lignende (uten å avgrense koden), men det viste seg at det ikke fantes noen slik implementering i fellesskapsversjonen ennå.
Generell arbeidsordning
La oss som et eksempel sette opp godkjenninger for sammenslåingsforespørsel på et testlager :
- La oss lage et token for å få tilgang til GitLab API (via det vil vi motta informasjon om antall stemmer for og imot)
- Legg til et token til GitLab-variabler
- Deaktiver Merge hvis det er feil i pipelinen (hvis det ikke er nok "for" stemmer)
- Sett opp stemmevalidering som en del av CI/CD-pipeline
- Vi vil forby å forplikte oss til beskyttede grener, vi gjør alle endringer kun gjennom MR
- La oss sjekke hva som skjedde til slutt
1. Opprett et token for å få tilgang til API
Gå til Brukerinnstillinger → Access Tokens og skriv ned tokenet:
Konto for å motta token
API-tilgang lar deg gjøre nesten hva som helst med lagrene dine, så jeg foreslår at du oppretter en separat Gitlab-konto, gir den minimale rettigheter til lagrene dine (som Reporter) og får et token for den kontoen.
2. Legg tokenet til Gitlab-variabler
For eksempel, i forrige trinn, mottok vi et token QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Åpne Innstillinger → CI/CD → Variabler → Legg til variabel → GITLAB_TOKEN_FOR_CI
Som et resultat får vi:
Dette kan gjøres både på ett depot og på en gruppe med depoter.
3. Vi setter forbud mot Merge dersom godkjenning fra kollegaer ikke mottas etter kodegjennomgangen
I vårt tilfelle vil forbudet mot Merge være at monteringsrørledningen vil returnere en feil dersom det ikke er nok stemmer.
Gå til Innstillinger → Generelt → Sammenslåingsforespørsler → Sammenslåingssjekker og aktiver alternativet Monteringslinjer må kjøre.
4. Sett opp rørledningen
Hvis du ikke har laget en CI/CD-pipeline for applikasjonen din ennå
Opprett en fil i roten til depotet .gitlab-ci.yml med enkelt innhold:
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 depot for CI/CD-konfigurasjon
Jeg vil anbefale å lage et eget depot der du må lage en myapp.gitlab-ci.yml-fil for å sette opp pipelinen. På denne måten kan du bedre kontrollere tilgangen til bidragsytere som kan endre byggepipeline og få et tilgangstoken.
Plasseringen av den nye pipeline-filen må spesifiseres ved å gå til myapp-depotet - Innstillinger - CI / CD - Monteringslinjer - Egendefinert CI-konfigurasjonsbane - angi en ny fil, for eksempel myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Tips: Bruk en linter for å gjøre endringer i GitLab CI-filer
Selv om du jobber alene, vil det å jobbe gjennom MR være en god hjelper, og kjøre alle endringene dine i pipeline-filene gjennom linter. Hvis du gjør en feil i syntaksen til YAML-filen, vil dette ikke tillate deg å bryte arbeidsrørledningen, men vil ganske enkelt blokkere Merge.
Et eksempel på beholdere med linters som du kan bygge inn i rørledningen din:
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 gjenstår å legge til noen få parametere til rørledningen din for å få den til å fungere:
stages:
- test
variables:
NEED_VOTES: 1
include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"
NEED_VOTES-variabelen bestemmer hvor mange "tommel opp" MR må ha for at Merge skal være tilgjengelig. En verdi på én betyr at du selv kan godkjenne din MR ved å "like" den.
inkluderer inkluderer teststadiet, som sjekker antall "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
Innhold i 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/.*$/'
Finn ut mer om hva som skjer når du sjekker:
- begrensningen er satt til at kontrollen vil være kun når du oppretter en MR i master- eller release /*-grenene
- ved å bruke GitLab API, få antall "likes" og "dislikes"
- beregne forskjellen mellom positive og negative svar
- hvis forskjellen er mindre enn verdien vi angir i NEED_VOTES, blokkerer vi muligheten til å slå sammen
5. Deaktiver forplikter seg til beskyttede grener
Vi bestemmer hvilke grener vi skal gjennomføre kodegjennomgang for og indikerer at de kun kan arbeides med gjennom MR.
For å gjøre dette, gå til Innstillinger → Depot → Beskyttede grener:
6. Kontroll
Sett NEED_VOTES: 0
Vi gjør MR og setter en «misliker».
I byggeloggene:
Sett nå "liker" og kjør en ny sjekk:
Kilde: www.habr.com