Ien fan 'e meast nedige funksjes, dy't net yn' e fergese ferzje fan GitLab is, is de mooglikheid om te stimmen tsjin repository-nullifikaasje en kontrôle Merge request (MR), mei help fan de ferplichte koadebeoardieling.
Litte wy sels de minimale funksjonaliteit dwaan - wy sille Merge ferbiede oant ferskate ûntwikkelders MR in thumbs up jouwe.
Wêrom is dit hielendal?
Us organisaasje kin maklik betelje om in GitLab-lisinsje te keapjen. Mar, om't ûntwikkeling wurdt útfierd yn in sletten lus sûnder tagong ta ynternet, en d'r is strikte budzjetplanning, kin de oankeap fan selsbehearde lisinsjes mei de nedige funksjonaliteit in protte moannen slepe, mar no moat it wurk dien wurde.
As gefolch moatte jo:
- of folslein ferbiede Fúzje yn beskerme tûken foar guon ûntwikkelders, mar dan ûntwikkelders dy't it rjocht hawwe om te fusearjen krije konflikten by it fusearjen fan MR's fan oare minsken as bonus;
- of jou de mooglikheid om uncontrolled fúzjes mei jo master tûke sûnder koade review, sels as it is Junior, dy't waard ynhierd krekt juster.
It earste wat ik die wie Google, yn 'e leauwige dat ien perfoarst al wat ferlykber dien hie (sûnder de koade te feroarjen), mar it die bliken dat d'r noch gjin sa'n ymplemintaasje wie yn 'e mienskipferzje.
Algemiene skema fan wurk
Litte wy as foarbyld de goedkarring fan Merge-fersyk konfigurearje op in testrepository :
- Litte wy in token meitsje foar tagong ta de GitLab API (troch it krije wy ynformaasje oer it oantal stimmen "foar" en "tsjin")
- Litte wy it token tafoegje oan de GitLab-fariabelen
- Litte wy Merge útskeakelje yn gefal fan flaters yn 'e pipeline (as d'r net genôch upvotes binne)
- Litte wy stimferifikaasje ynstelle as ûnderdiel fan 'e CI / CD-pipeline
- Wy ferbiede it meitsjen fan commits foar beskerme tûken; alle wizigingen wurde allinich makke fia MR
- Litte wy kontrolearje wat der úteinlik bard is
1. Meitsje in token om tagong te krijen ta de API
Gean nei Brûkerynstellingen → Tokens tagong en skriuw it token op:
Account om in token te ûntfangen
API-tagong lit jo hast alles dwaan mei jo repositories, dus ik advisearje it meitsjen fan in apart Gitlab-akkount, it jaan fan minimale rjochten foar jo repositories (bgl. Reporter) en in token krije foar dat akkount.
2. Foegje de token ta oan de Gitlab fariabelen
Bygelyks, yn 'e foarige stap krigen wy in token QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Iepenje Ynstellings → CI/CD → Fariabelen → Fariabel taheakje → GITLAB_TOKEN_FOR_CI
As gefolch krije wy:
Dit kin dien wurde op ien repository of op in groep repositories.
3. Wy sette in ferbod op Merge as de goedkarring fan kollega is net ûntfongen nei de koade review.
Yn ús gefal sil it ferbod op Merge wêze dat de montagepipeline in flater werombringt as der net genôch stimmen binne.
Gean nei Ynstellings → Algemien → Fersiken gearfoegje → Kontrôles gearfoegje en aktivearje de opsje Assembly rigels moatte suksesfol foltôgje.
4. It opsetten fan de pipeline
As jo noch gjin CI / CD-pipeline hawwe makke foar jo applikaasje
Meitsje in bestân yn 'e root fan it repository .gitlab-ci.yml mei de ienfâldichste ynhâld:
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"
Separate repository foar CI / CD konfiguraasje
Ik soe riede in aparte repository te meitsjen wêryn jo in myapp.gitlab-ci.yml-bestân moatte oanmeitsje om de pipeline te konfigurearjen. Op dizze manier kinne jo de tagong fan dielnimmers better kontrolearje dy't de buildpipeline kinne feroarje en in tagongstoken krije.
De lokaasje fan it nije pipeline-bestân sil moatte wurde opjûn troch te gean nei it myapp-repository - Ynstellings - CI / CD - Assembly rigels - Oanpaste CI-konfiguraasjepaad - spesifisearje it nije bestân, bgl. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Tip: Brûk in linter om wizigingen te meitsjen oan GitLab CI-bestannen
Sels as jo allinich wurkje, sil wurkje fia MR in goede help wêze, al jo wizigingen yn pipelinebestannen troch in linter útfiere. As jo in flater meitsje yn 'e syntaksis fan it YAML-bestân, sil it jo produksjepipeline net brekke, mar sil gewoan Merge blokkearje.
In foarbyld fan konteners mei linters dy't jo yn jo pipeline kinne bouwe:
En in foarbyld fan it ferifikaasjestadium:
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;
It bliuwt om in pear parameters ta te foegjen oan jo pipeline om it te wurkjen:
stages:
- test
variables:
NEED_VOTES: 1
include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"
De NEED_VOTES fariabele bepaalt hoefolle "thumbs up" MR moat hawwe om Merge beskikber te wêzen. In wearde gelyk oan ien betsjut dat jo sels jo MR goedkarre kinne troch it te "liken".
omfettet it testpoadium, dat it oantal "likes" kontrolearret.
De ienfâldichste pipeline mei it foarbyld fan myapp.gitlab-ci.yml
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
Ynhâld 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/.*$/'
Mear ynformaasje oer wat der bart by ferifikaasje:
- der is in beheining dat de kontrôle wurdt allinnich dien by it meitsjen fan MR yn de master of release / * tûken
- mei de GitLab API krije wy it oantal "likes" en "dislikes"
- berekkenje it ferskil tusken positive en negative reaksjes
- as it ferskil minder is dan de wearde dy't wy yn NEED_VOTES ynsteld hawwe, blokkearje wy de mooglikheid om te fusearjen
5. Ferbiede commits oan beskerme tûken
Wy definiearje de tûken wêrfoar wy koadebeoardielingen moatte fiere en jouwe oan dat se allinich fia MR kinne wurde wurke.
Om dit te dwaan, gean nei Ynstellings → Repository → Beskerme tûken:
6. Kontrolearje
Set NEED_VOTES: 0
Wy meitsje in MR en sette in "dislike".
Yn de boulogs:
Set no "like" en begjin opnij te kontrolearjen:
Boarne: www.habr.com