GitLab-ın pulsuz versiyasında olmayan ən çox ehtiyac duyulan xüsusiyyətlərdən biri, məcburi kodun nəzərdən keçirilməsindən istifadə edərək Birləşdirmə sorğusuna (MR) nəzarət etmək üçün deponun sıfırlanmasına qarşı səs vermək imkanıdır.
Minimum funksionallığı özümüz edəcəyik - bir neçə tərtibatçı MR-ə "bəyənmə" verənə qədər Birləşməni söndürəcəyik.
Bu ümumiyyətlə niyə belədir?
Təşkilatımızın GitLab lisenziyası almağa imkanı var. Lakin, inkişaf İnternetə çıxışı olmayan qapalı bir dövrədə həyata keçirildiyindən və ciddi bir büdcə planlaşdırması olduğundan, lazımi funksionallıqla özünü idarə edən lisenziyaların alınması bir neçə ay çəkə bilər və indi işləmək lazımdır.
Nəticədə, etməlisiniz:
- və ya bəzi tərtibatçılar üçün Qorunan filiallara Birləşməni tamamilə qadağan edin, lakin sonra Birləşmə hüququ olan tərtibatçılar bonus olaraq digər insanların MR-lərini birləşdirərkən münaqişələr alırlar;
- və ya dünən məskunlaşmış bir Junior olsa belə, kod nəzərdən keçirmədən master filialınızla nəzarətsiz birləşmələr etməyə icazə verin.
İlk etdiyim şey kiminsə buna bənzər bir şey etdiyinə (kodu dəqiqləşdirmədən) inanaraq google-a getmək oldu, lakin məlum oldu ki, icma versiyasında hələ belə bir tətbiq yoxdur.
Ümumi iş sxemi
Nümunə olaraq, test deposunda Birləşdirmə sorğusu təsdiqlərini quraşdıraq :
- GitLab API-yə daxil olmaq üçün bir işarə yaradaq (onun vasitəsilə biz lehinə və əleyhinə səslərin sayı haqqında məlumat alacağıq)
- GitLab dəyişənlərinə işarə əlavə edin
- Boru kəmərində səhvlər varsa (kifayət qədər "lehinə" səslər yoxdursa) Birləşməni söndürün
- CI/CD boru kəmərinin bir hissəsi kimi səs təsdiqini qurun
- Biz qorunan filiallara öhdəlik götürməyi qadağan edəcəyik, bütün dəyişiklikləri yalnız MR vasitəsilə edirik
- Sonda nə baş verdiyini yoxlayaq
1. API-yə daxil olmaq üçün nişan yaradın
İstifadəçi Parametrləri → Tokenlərə daxil olun və nişanı yazın:
Token almaq üçün hesab
API girişi sizə depolarınızla demək olar ki, hər şeyi etməyə imkan verir, ona görə də sizə ayrıca Gitlab hesabı yaratmağı, ona repozitoriyalarınıza minimal hüquqlar vermənizi (Məsələn kimi) və həmin hesab üçün nişan almağı təklif edirəm.
2. Tokeni Gitlab dəyişənlərinə əlavə edin
Məsələn, əvvəlki addımda bir token aldıq QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Parametrlər → CI/CD → Dəyişənlər → Dəyişən əlavə et → açın GITLAB_TOKEN_FOR_CI
Nəticədə əldə edirik:
Bu, həm bir depoda, həm də bir qrup depoda edilə bilər.
3. Kod nəzərdən keçirildikdən sonra həmkarların razılığı alınmazsa, Birləşməyə qadağa qoyuruq.
Bizim vəziyyətimizdə, Birləşməyə qadağa, kifayət qədər səs olmadıqda montaj boru kəmərinin bir səhv qaytarması olacaq.
Parametrlər → Ümumi → Sorğuları birləşdirin → Yoxlamaları birləşdirin və Assambleya xətləri uğurla işləməlidir seçimini aktivləşdirin.
4. Boru kəmərini quraşdırın
Əgər ərizəniz üçün hələ də CI/CD boru xətti yaratmamısınızsa
Repozitoriyanın kökündə bir fayl yaradın .gitlab-ci.yml sadə məzmunu ilə:
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"
CI/CD konfiqurasiyası üçün ayrıca depo
Boru kəmərini quraşdırmaq üçün myapp.gitlab-ci.yml faylı yaratmağınız lazım olan ayrıca repozitoriya yaratmağı tövsiyə edərdim. Bu yolla siz tikinti boru kəmərini dəyişdirə və giriş nişanı əldə edə bilən ianəçilərin girişinə daha yaxşı nəzarət edə bilərsiniz.
Yeni boru kəməri faylının yerini myapp deposuna keçməklə müəyyən etmək lazımdır - Parametrlər - CI / CD - Montaj xətləri - Fərdi CI konfiqurasiya yolu - məsələn, yeni faylı göstərin myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
İpucu: GitLab CI fayllarında dəyişiklik etmək üçün linterdən istifadə edin
Tək işləsəniz belə, MR vasitəsilə işləmək, boru kəməri fayllarına bütün dəyişikliklərinizi linter vasitəsilə həyata keçirmək üçün yaxşı kömək olacaq. YAML faylının sintaksisində səhv etsəniz, bu, işləyən boru kəmərini pozmağa imkan verməyəcək, sadəcə Birləşməni bloklayacaq.
Boru kəmərinizə yerləşdirə biləcəyiniz linterləri olan konteynerlərə bir nümunə:
Və təsdiqləmə mərhələsinə bir nümunə:
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;
Onun işləməsi üçün boru kəmərinizə bir neçə parametr əlavə etmək qalır:
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 dəyişəni Merge-nin əlçatan olması üçün MR-nin neçə "bəyənmə" olması lazım olduğunu müəyyən edir. Bir dəyəri o deməkdir ki, siz özünüz MR-ni "bəyənərək" təsdiq edə bilərsiniz.
"like"ların sayını yoxlayan test mərhələsi daxildir.
Nümunə olaraq myapp.gitlab-ci.yml istifadə edən ən sadə boru kəməri
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
check-approve.gitlab-ci.yml məzmunu
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/.*$/'
Yoxlama zamanı baş verənlər haqqında ətraflı məlumat əldə edin:
- məhdudiyyət müəyyən edilir ki, çek yalnız master-da MR yaratdıqda və ya /* filiallarını buraxdıqda olacaq
- GitLab API istifadə edərək, "bəyənmə" və "bəyənməmə" sayını əldə edin
- müsbət və mənfi cavablar arasındakı fərqi hesablayın
- fərq NEED_VOTES-də təyin etdiyimiz dəyərdən azdırsa, onda birləşmə qabiliyyətini bloklayırıq
5. Qorunan filiallara öhdəlikləri deaktiv edin
Kod nəzərdən keçirməli olduğumuz filialları müəyyənləşdiririk və onların yalnız MR vasitəsilə işlənə biləcəyini bildiririk.
Bunu etmək üçün Parametrlər → Repozitoriya → Qorunan Filiallara keçin:
6. Yoxlama
NEED_VOTES təyin edin: 0
MR edirik və "dislike" qoyuruq.
Quraşdırma qeydlərində:
İndi "like" qoyun və yenidən yoxlayın:
Mənbə: www.habr.com