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
Contents 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
МР жасап, “дизлайк” коебуз.
Куруу журналдарында:
Эми "лайк" коюңуз жана кайра текшерип баштаңыз:
Source: www.habr.com