Ein nauðsynlegasta aðgerðin, sem er ekki í ókeypis útgáfunni af GitLab, er hæfileikinn til að greiða atkvæði gegn ógildingu geymslu og stjórna samrunabeiðni (MR), með því að nota lögboðna endurskoðun kóðans.
Við skulum gera lágmarksvirkni sjálf - við munum banna Samruna þar til nokkrir forritarar gefa MR þumalfingur upp.
Hvers vegna er þetta jafnvel nauðsynlegt?
Samtökin okkar hafa auðveldlega efni á að kaupa GitLab leyfi. En þar sem þróun fer fram í lokuðu lykkju án netaðgangs og ströng fjárhagsáætlun er fyrir hendi, geta kaup á sjálfstýrð leyfum með nauðsynlegri virkni dregist á langinn í marga mánuði, en nú þarf að vinna.
Þar af leiðandi þarftu að:
- eða banna algjörlega sameiningu í vernduðum útibúum fyrir suma þróunaraðila, en þá fá verktaki sem hafa rétt til að sameina átök við sameiningu MR-manna annarra sem bónus;
- eða gefðu þér tækifæri til að gera stjórnlausar sameiningar við meistaraútibúið þitt án kóðaskoðunar, jafnvel þótt það sé Junior, sem var ráðinn í gær.
Það fyrsta sem ég gerði var að Google, trúði því að einhver hefði örugglega þegar gert eitthvað svipað (án þess að breyta kóðanum), en það kom í ljós að það var engin slík útfærsla í samfélagsútgáfunni ennþá.
Almennt vinnukerfi
Sem dæmi skulum við stilla samþykki samrunabeiðna á prófunargeymslu :
- Búum til tákn fyrir aðgang að GitLab API (í gegnum það fáum við upplýsingar um fjölda atkvæða "með" og "á móti")
- Við skulum bæta tákninu við GitLab breyturnar
- Slökktum á sameiningu ef villur koma upp í leiðslunni (ef það eru ekki nógu mörg atkvæði)
- Setjum upp atkvæðastaðfestingu sem hluta af CI/CD leiðslunni
- Við bönnum að skuldbinda okkur til verndaðra útibúa; allar breytingar eru aðeins gerðar í gegnum MR
- Athugum hvað gerðist á endanum
1. Búðu til tákn til að fá aðgang að API
Farðu í Notendastillingar → Aðgangstákn og skrifaðu niður táknið:
Reikningur til að fá tákn
API aðgangur gerir þér kleift að gera nánast hvað sem er við geymslurnar þínar, svo ég mæli með að búa til sérstakan Gitlab reikning, gefa honum lágmarksréttindi á geymslurnar þínar (td Reporter) og fá tákn fyrir þann reikning.
2. Bættu tákninu við Gitlab breyturnar
Til dæmis, í fyrra skrefi fengum við tákn QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Opnaðu Stillingar → CI/CD → Breytur → Bæta við breytu → GITLAB_TOKEN_FOR_CI
Fyrir vikið fáum við:
Þetta er hægt að gera annaðhvort á einni geymslu eða á hópi geymslum.
3. Við setjum bann við sameiningu ef samþykki samstarfsmanna berst ekki eftir endurskoðun kóðans.
Í okkar tilviki mun bannið við sameiningu vera það að samsetningarleiðslan skili villu ef atkvæði eru ekki næg.
Farðu í Stillingar → Almennar → Sameiningabeiðnir → Sameiningaávísanir og virkjaðu valkostinn Samsetningarlínur verða að ljúka með góðum árangri.
4. Uppsetning leiðslunnar
Ef þú hefur ekki enn búið til CI/CD leiðslu fyrir forritið þitt
Búðu til skrá í rót geymslunnar .gitlab-ci.yml með einfaldasta innihaldinu:
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"
Aðskilin geymsla fyrir CI/CD stillingar
Ég myndi mæla með því að búa til sérstaka geymslu þar sem þú þarft að búa til myapp.gitlab-ci.yml skrá til að stilla leiðsluna. Þannig geturðu betur stjórnað aðgangi þátttakenda sem geta breytt byggingarpípunni og fengið aðgangslykil.
Tilgreina þarf staðsetningu nýju leiðsluskrárinnar með því að fara í myapp geymsluna - Stillingar - CI/CD - Samsetningarlínur - Sérsniðin CI stillingarslóð - tilgreina nýju skrána, t.d. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Ábending: Notaðu linter til að gera breytingar á GitLab CI skrám
Jafnvel ef þú vinnur einn, mun vinna í gegnum MR vera góð hjálp, keyra allar breytingar þínar á leiðsluskrám í gegnum linter. Ef þú gerir mistök í setningafræði YAML skráarinnar mun hún ekki brjóta framleiðsluleiðsluna þína, heldur mun hún einfaldlega loka fyrir sameiningu.
Dæmi um ílát með linters sem þú getur byggt inn í leiðsluna þína:
Og dæmi um staðfestingarstigið:
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;
Það er eftir að bæta nokkrum breytum við leiðsluna þína til að það virki:
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 breytan ákvarðar hversu marga „thumbs up“ MR verður að hafa til þess að Merge sé tiltækt. Gildi jafnt og einum þýðir að þú getur sjálfur samþykkt MR þinn með því að "líka við" hann.
felur í sér prófunarstigið, sem athugar fjölda „like“.
Einfaldasta leiðslan með dæminu 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
Innihald 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/.*$/'
Frekari upplýsingar um hvað gerist við staðfestingu:
- það er takmörkun á því að athuga verður aðeins gert þegar MR er búið til í master eða útgáfu/* greinum
- með því að nota GitLab API fáum við fjölda „like“ og „mislíkar“
- reikna muninn á jákvæðum og neikvæðum svörum
- ef munurinn er minni en gildið sem við settum í NEED_VOTES, þá lokum við á möguleikann á að sameinast
5. Banna skuldbindur sig til verndaðra útibúa
Við skilgreinum útibúin sem við verðum að gera úttektir á reglum fyrir og gefum til kynna að einungis sé hægt að vinna með þau í gegnum MR.
Til að gera þetta, farðu í Stillingar → Geymsla → Vernduð útibú:
6. Athugaðu
Stilltu NEED_VOTES: 0
Við gerum MR og setjum „mislík“.
Í byggingarskrám:
Settu nú „like“ og byrjaðu að athuga aftur:
Heimild: www.habr.com