GitLab тегін нұсқасында жоқ ең қажетті функциялардың бірі - репозиторийді жоюға қарсы дауыс беру және кодты міндетті түрде тексеру арқылы Біріктіру сұрауын (MR) басқару.
Ең аз функционалдылықты өзіміз орындайық – бірнеше әзірлеушілер MR-ге оң баға бермейінше, біріктіруге тыйым саламыз.
Бұл не үшін қажет?
Біздің ұйым GitLab лицензиясын оңай сатып ала алады. Бірақ, әзірлеу Интернетке қосылусыз жабық циклде жүзеге асырылатындықтан және қатаң бюджеттік жоспарлау болғандықтан, қажетті функционалдығы бар өзін-өзі басқаратын лицензияларды сатып алу көптеген айларға созылуы мүмкін, бірақ қазір жұмыс істеу керек.
Нәтижесінде сізге қажет:
- немесе кейбір әзірлеушілер үшін қорғалған филиалдарда Біріктіруге толығымен тыйым салады, бірақ содан кейін біріктіруге құқығы бар әзірлеушілер бонус ретінде басқа адамдардың MR-ін біріктіру кезінде қайшылықтар алады;
- немесе кеше ғана жұмысқа қабылданған Джуниор болса да, кодты қарап шықпай-ақ басты филиалыңызбен бақыланбайтын біріктірулер жасауға мүмкіндік беріңіз.
Мен жасаған бірінші нәрсе Google болды, біреу міндетті түрде ұқсас нәрсені жасады деп сенді (кодты өзгертпей), бірақ қауымдастық нұсқасында мұндай енгізу әлі жоқ екені белгілі болды.
Жұмыстың жалпы схемасы
Мысал ретінде сынақ репозиторийінде Біріктіру сұрауын бекітуді теңшейік :
- GitLab API-ге кіруге арналған таңбалауыш жасайық (ол арқылы біз «жақтаған» және «қарсы» дауыстар саны туралы ақпаратты аламыз)
- Токенді GitLab айнымалыларына қосамыз
- Құбырда қателер болған жағдайда біріктіруді өшірейік (егер жақсы дауыстар жеткіліксіз болса)
- CI/CD құбырының бөлігі ретінде дауысты тексеруді орнатайық
- Біз қорғалған филиалдарға міндеттеме беруге тыйым саламыз, барлық өзгертулер тек MR арқылы жасалады
- Соңында не болғанын тексерейік
1. API интерфейсіне кіру үшін таңбалауышты жасаңыз
Пайдаланушы параметрлері → Токендерге қол жеткізу тармағына өтіп, таңбалауышты жазып алыңыз:
Токен алу үшін тіркелгі
API рұқсаты репозиторийлеріңізбен кез келген дерлік әрекетті орындауға мүмкіндік береді, сондықтан мен жеке Gitlab тіркелгісін жасауды ұсынамын, оған репозиторийлеріңізге (мысалы, Reporter) минималды құқықтар беріп, сол тіркелгі үшін таңбалауыш алыңыз.
2. Gitlab айнымалыларына таңбалауышты қосыңыз
Мысалы, алдыңғы қадамда біз жетон алдық QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Параметрлер → CI/CD → Айнымалылар → Айнымалы қосу → тармағын ашыңыз GITLAB_TOKEN_FOR_CI
Нәтижесінде біз аламыз:
Мұны бір репозиторийде де, репозиторийлер тобында да жасауға болады.
3. Егер кодты қарап шыққаннан кейін әріптестердің мақұлдауын алмаса, біріктіруге тыйым саламыз.
Біздің жағдайда біріктіруге тыйым салу, егер дауыс жеткіліксіз болса, құрастыру құбыры қатені қайтарады.
Параметрлер → Жалпы → Сұрауларды біріктіру → Тексерулерді біріктіру тармағына өтіп, «Құрастыру жолдары сәтті аяқталуы керек» опциясын қосыңыз.
4. Құбырды орнату
Қолданбаңыз үшін CI/CD құбырын әлі жасамаған болсаңыз
Репозиторийдің түбірінде файл жасаңыз .gitlab-ci.yml ең қарапайым мазмұнмен:
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 конфигурациясына арналған бөлек репозиторий
Құбырды конфигурациялау үшін myapp.gitlab-ci.yml файлын жасау қажет жеке репозиторий жасауды ұсынамын. Осылайша сіз құрастыру құбырын өзгерте алатын және кіру таңбалауышын ала алатын қатысушылардың қатынасын жақсырақ басқара аласыз.
Жаңа конфигурация файлының орнын myapp репозиторийіне өту арқылы көрсету керек - Параметрлер - CI/CD - Құрастыру жолдары - Теңшелетін CI конфигурация жолы - жаңа файлды көрсетіңіз, мысалы. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Кеңес: GitLab CI файлдарына өзгертулер енгізу үшін линтер пайдаланыңыз
Жалғыз жұмыс істесеңіз де, MR арқылы жұмыс істеу жақсы көмек болады, құбыр файлдарына жасалған барлық өзгерістерді линтер арқылы іске қосады. YAML файлының синтаксисінде қателессеңіз, ол сіздің өндірістік құбырыңызды бұзбайды, тек Біріктіруді блоктайды.
Құбырға салуға болатын линтерлері бар контейнерлердің мысалы:
Және тексеру кезеңінің мысалы:
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;
Ол жұмыс істеуі үшін құбырыңызға бірнеше параметрлерді қосу керек:
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 айнымалысы Біріктіру қол жетімді болуы үшін MR-де қанша «жоғары бармақ» болуы керектігін анықтайды. Бірге тең мән сіздің MR-ді «ұнату» арқылы өзіңіз бекіте алатыныңызды білдіреді.
қосу «ұнату» санын тексеретін сынақ кезеңін қамтиды.
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
Мазмұны 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/.*$/'
Тексеру кезінде не болатыны туралы қосымша ақпарат:
- Тексеру тек қана мастерде немесе шығару/* тармақтарында MR жасағанда орындалатынына шектеу бар
- GitLab API көмегімен біз «ұнату» және «ұнатпау» санын аламыз
- оң және теріс жауаптардың айырмашылығын есептеңіз
- егер айырмашылық NEED_VOTES-те орнатқан мәннен аз болса, біз біріктіру мүмкіндігін блоктаймыз
5. Қорғалатын филиалдарға міндеттемелерге тыйым салу
Біз кодтық шолуды жүргізуіміз керек филиалдарды анықтаймыз және олармен тек MR арқылы жұмыс істеуге болатынын көрсетеміз.
Ол үшін Параметрлер → Репозиторий → Қорғалған филиалдар тармағына өтіңіз:
6. Тексеріңіз
NEED_VOTES орнатыңыз: 0
Біз МР жасап, «ұнатпау» қоямыз.
Құрастыру журналдарында:
Енді «лайк» белгісін қойып, қайтадан тексеруді бастаңыз:
Ақпарат көзі: www.habr.com