بررسی کد در Gitlab CE: اگر تأییدیه درخواست ادغام وجود نداشته باشد، اما من واقعاً می خواهم

یکی از ویژگی های مورد نیاز که در نسخه رایگان GitLab وجود ندارد، امکان رای مخالف به صفر کردن مخزن برای کنترل درخواست Merge (MR) با استفاده از بررسی کد اجباری است.

ما حداقل عملکرد را خودمان انجام خواهیم داد - تا زمانی که چندین برنامه‌نویس به MR پاسخ مثبت دهند، Merge را غیرفعال می‌کنیم.

اصلا چرا اینجوریه؟

سازمان ما توانایی خرید مجوز GitLab را دارد. اما، از آنجایی که توسعه در یک حلقه بسته بدون دسترسی به اینترنت انجام می شود و برنامه ریزی بودجه دقیقی وجود دارد، خرید مجوزهای خود مدیریت با عملکرد لازم می تواند ماه ها طول بکشد و اکنون باید کار کنید.

در نتیجه، شما باید:

• یا به طور کامل ادغام در شاخه های محافظت شده را برای برخی از توسعه دهندگان ممنوع کنید، اما توسعه دهندگانی که حق ادغام را دارند، در هنگام ادغام MR های دیگران به عنوان پاداش، درگیری دریافت می کنند.
• یا به شما اجازه می دهد تا بدون بازبینی کد، ادغام های کنترل نشده ای را با شعبه اصلی خود انجام دهید، حتی اگر جوانی باشد که به تازگی در دیروز مستقر شده است.

اولین کاری که انجام دادم این بود که به گوگل مراجعه کردم، با این باور که شخصی قبلاً کاری مشابه انجام داده است (بدون اصلاح کد)، اما معلوم شد که هنوز چنین پیاده سازی در نسخه انجمن وجود ندارد.

طرح کلی کار

به عنوان مثال، اجازه دهید تأییدیه های درخواست ادغام را در یک مخزن آزمایشی تنظیم کنیم myapp:

1. بیایید یک توکن برای دسترسی به API GitLab ایجاد کنیم (از طریق آن اطلاعاتی در مورد تعداد رای موافق و مخالف دریافت خواهیم کرد)
2. یک توکن به متغیرهای GitLab اضافه کنید
3. در صورت وجود خطایی در خط لوله، ادغام را غیرفعال کنید (اگر رای «برای» کافی وجود ندارد)
4. اعتبارسنجی رأی را به عنوان بخشی از خط لوله CI/CD تنظیم کنید
5. ما تعهد به شاخه های محافظت شده را ممنوع خواهیم کرد، ما همه تغییرات را فقط از طریق MR انجام می دهیم
6. بیایید بررسی کنیم که در پایان چه اتفاقی افتاده است

1. یک توکن برای دسترسی به API ایجاد کنید

به تنظیمات کاربر → Access Tokens بروید و توکن را یادداشت کنید:

حساب برای دریافت رمز
دسترسی API به شما امکان می دهد تقریباً هر کاری را با مخازن خود انجام دهید، بنابراین پیشنهاد می کنم یک حساب Gitlab جداگانه ایجاد کنید، حداقل حقوق را به مخازن خود (مانند Reporter) بدهید و یک توکن برای آن حساب دریافت کنید.

2. توکن را به متغیرهای Gitlab اضافه کنید

به عنوان مثال در مرحله قبل یک توکن دریافت کردیم QmN2Y0NOUFlfeXhvd21ZS01aQzgK

تنظیمات → CI/CD → متغیرها → افزودن متغیر → را باز کنید GITLAB_TOKEN_FOR_CI

در نتیجه، دریافت می کنیم:

این را می توان هم در یک مخزن و هم در گروهی از مخازن انجام داد.

3. در صورت عدم تایید همکاران پس از بررسی کد، ادغام را منع می کنیم

در مورد ما، ممنوعیت Merge به این صورت خواهد بود که خط لوله مونتاژ در صورتی که رای کافی وجود نداشته باشد، خطایی را برمی‌گرداند.

به تنظیمات ← عمومی ← درخواست ادغام ← بررسی ادغام بروید و گزینه خطوط مونتاژ باید با موفقیت اجرا شود را فعال کنید.

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 اشتباه کنید، این به شما اجازه نمی دهد خط لوله کار را بشکنید، بلکه به سادگی Merge را مسدود می کند.

نمونه ای از ظروف با لنگر که می توانید در خط لوله خود جاسازی کنید:

hub.docker.com/r/gableroux/gitlab-ci-lint
hub.docker.com/r/sebiwi/gitlab-ci-validate

و نمونه ای از مرحله اعتبار سنجی:

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