Kode-hersiening in Gitlab CE: as daar geen samesmeltingsversoekgoedkeurings is nie, maar ek wil regtig

Een van die mees benodigde kenmerke wat nie in die gratis weergawe van GitLab is nie, is die vermoë om teen die nulstelling van die bewaarplek te stem om die Merge-versoek (MR) te beheer deur die verpligte kodehersiening te gebruik.

Ons sal die minimum funksionaliteit self doen - ons sal Merge deaktiveer totdat verskeie ontwikkelaars 'n "thumbs up" vir MR gee.

Hoekom is dit enigsins?

Ons organisasie kan bekostig om 'n GitLab-lisensie te koop. Maar aangesien die ontwikkeling in 'n geslote lus sonder toegang tot die internet uitgevoer word, en daar 'n streng begrotingsbeplanning is, kan die aankoop van selfbestuurde lisensies met die nodige funksionaliteit baie maande neem, en jy moet nou werk.

As gevolg hiervan moet jy:

• of die samesmelting in beskermde takke vir sommige ontwikkelaars heeltemal verbied, maar dan ontvang ontwikkelaars wat die reg het om saam te smelt konflikte wanneer ander mense se MR'e saamgevoeg word as 'n bonus;
• of laat jou toe om onbeheerde samesmeltings met jou meestertak te doen sonder kodehersiening, selfs al is dit 'n Junior wat net gister gevestig het.

Die eerste ding wat ek gedoen het, was om te gaan google, en glo dat iemand reeds iets soortgelyks gedoen het (sonder om die kode te verfyn), maar dit het geblyk dat daar nog nie so 'n implementering in die gemeenskapsweergawe was nie.

Algemene skema van werk

Kom ons stel as voorbeeld Samevoegversoekgoedkeurings op 'n toetsbewaarplek op myapp:

1. Kom ons skep 'n teken vir toegang tot die GitLab API (daardeur sal ons inligting ontvang oor die aantal stemme vir en teen)
2. Voeg 'n teken by GitLab-veranderlikes
3. Deaktiveer samesmelting as daar foute in die pyplyn is (as daar nie genoeg "vir" stemme is nie)
4. Stel stemvalidering op as deel van die CI/CD-pyplyn
5. Ons sal verbied om verbintenisse tot beskermde takke te maak, ons maak alle veranderinge slegs deur MR
6. Kom ons kyk wat op die ou end gebeur het

1. Skep 'n teken om toegang tot die API te verkry

Gaan na Gebruikerinstellings → Toegangtokens en skryf die teken neer:

Rekening om die teken te ontvang
API-toegang laat jou toe om byna enigiets met jou bewaarplekke te doen, so ek stel voor jy skep 'n aparte Gitlab-rekening, gee dit minimale regte op jou bewaarplekke (soos Reporter) en kry 'n teken vir daardie rekening.

2. Voeg die teken by Gitlab-veranderlikes

Byvoorbeeld, in die vorige stap het ons 'n teken ontvang QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Maak Instellings → CI/CD → Veranderlikes → Voeg veranderlike by → oop GITLAB_TOKEN_FOR_CI

As gevolg hiervan kry ons:

Dit kan beide op een bewaarplek en op 'n groep bewaarplekke gedoen word.

3. Ons plaas 'n verbod op Merge as die goedkeuring van kollegas nie ontvang word na die kode hersiening nie

In ons geval sal die verbod op Merge wees dat die monteerpyplyn 'n fout sal gee as daar nie genoeg stemme is nie.

Gaan na Instellings → Algemeen → Samevoegversoeke → Voeg tjeks saam en aktiveer die opsie Montagelyne moet suksesvol loop.

4. Stel die pyplyn op

As jy nog nie 'n CI/CD-pyplyn vir jou aansoek gemaak het nie
Skep 'n lêer in die wortel van die bewaarplek .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"

Afsonderlike bewaarplek vir CI/CD-konfigurasie
Ek sal aanbeveel om 'n aparte bewaarplek te maak waar jy 'n myapp.gitlab-ci.yml-lêer moet skep om die pyplyn op te stel. Op hierdie manier kan jy die toegang van bydraers beter beheer wat die boupyplyn kan verander en 'n toegangsteken kan kry.

Die ligging van die nuwe pyplynlêer sal gespesifiseer moet word deur na die myapp-bewaarplek te gaan - Instellings - CI / CD - Monteerlyne - Pasgemaakte CI-konfigurasiepad - spesifiseer 'n nuwe lêer, byvoorbeeld myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Wenk: Gebruik 'n linter om veranderinge aan GitLab CI-lêers aan te bring
Selfs as jy alleen werk, sal dit 'n goeie helper wees om deur MR te werk en al jou veranderinge aan die pyplynlêers deur die linter te laat loop. As jy 'n fout maak in die sintaksis van die YAML-lêer, sal dit jou nie toelaat om die werkende pyplyn te breek nie, maar sal eenvoudig Merge blokkeer.

'n Voorbeeld van houers met linters wat jy in jou pyplyn kan insluit:

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

En 'n voorbeeld van die validering stadium:

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;

Dit bly om 'n paar parameters by jou pyplyn te voeg om dit te laat werk:

stages:
- test

variables:
NEED_VOTES: 1

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

Die NEED_VOTES veranderlike bepaal hoeveel "thumbs up" MR moet hê sodat Merge beskikbaar is. 'n Waarde van een beteken dat jy self jou MR kan goedkeur deur dit te "like".

sluit die toetsstadium in, wat die aantal "laaiks" kontroleer.

Die eenvoudigste pyplyn met myapp.gitlab-ci.yml as 'n 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/.*$/'


Kom meer te wete oor wat gebeur wanneer u nagaan:

• die beperking is gestel dat die tjek slegs sal wees wanneer 'n MR in die meester- of vrystelling /*-takke geskep word
• gebruik die GitLab API, kry die aantal "laaiks" en "hou nie van"
• bereken die verskil tussen positiewe en negatiewe reaksies
• as die verskil minder is as die waarde wat ons in NEED_VOTES gestel het, dan blokkeer ons die vermoë om saam te smelt

5. Deaktiveer verbind tot beskermde takke

Ons bepaal die takke waarvoor ons kode-hersiening moet doen en dui aan dat daar slegs deur MR met hulle gewerk kan word.

Om dit te doen, gaan na Instellings → Bewaarplek → Beskermde takke:

6. Kontroleer

Stel NEED_VOTES: 0

Ons doen MR en plaas 'n "dislike".

In die boulogboeke:

Plaas nou "like" en voer 'n herkontrole uit:

Bron: will.com