مراجعة الكود في Gitlab CE: إذا لم تكن هناك موافقات على طلب الدمج ، لكنني أريد ذلك حقًا

واحدة من أكثر الميزات المطلوبة غير الموجودة في الإصدار المجاني من GitLab هي القدرة على التصويت ضد تصفية المستودع للتحكم في طلب الدمج (MR) باستخدام مراجعة التعليمات البرمجية الإلزامية.

سنفعل الحد الأدنى من الوظائف بأنفسنا - سنقوم بتعطيل الدمج حتى يقدم العديد من المطورين "إعجابًا" إلى MR.

لماذا هذا على الاطلاق؟

يمكن لمؤسستنا شراء ترخيص GitLab. ولكن ، نظرًا لأن التطوير يتم في حلقة مغلقة دون الوصول إلى الإنترنت ، وهناك تخطيط صارم للميزانية ، فقد يستغرق شراء التراخيص المدارة ذاتيًا بالوظائف الضرورية عدة أشهر ، وتحتاج إلى العمل الآن.

نتيجة لذلك ، عليك أن:

• أو حظر الدمج تمامًا في الفروع المحمية لبعض المطورين ، ولكن بعد ذلك ، يتلقى المطورون الذين لديهم الحق في الدمج تعارضات عند دمج MRs لأشخاص آخرين كمكافأة ؛
• أو تسمح لك بإجراء عمليات دمج غير خاضعة للرقابة مع فرعك الرئيسي دون مراجعة الكود ، حتى لو كان مبتدئًا استقر للتو بالأمس.

أول شيء فعلته هو الانتقال إلى google ، معتقدًا أن شخصًا ما قد فعل شيئًا مشابهًا بالفعل (بدون تنقيح الكود) ، ولكن اتضح أنه لم يكن هناك مثل هذا التنفيذ في إصدار المجتمع حتى الآن.

مخطط العمل العام

على سبيل المثال ، لنقم بإعداد موافقات طلب الدمج في مستودع اختبار تطبيقي:

1. دعنا ننشئ رمزًا مميزًا للوصول إلى GitLab API (من خلاله سنتلقى معلومات حول عدد الأصوات المؤيدة والمعارضة)
2. أضف رمزًا مميزًا إلى متغيرات GitLab
3. تعطيل الدمج إذا كانت هناك أخطاء في خط الأنابيب (إذا لم يكن هناك عدد كافٍ من الأصوات "لصالح")
4. قم بإعداد التحقق من صحة التصويت كجزء من خط أنابيب CI / CD
5. سنحظر تقديم التزامات للفروع المحمية ، ونقوم بإجراء جميع التغييرات فقط من خلال MR
6. دعونا نتحقق مما حدث في النهاية

1. قم بإنشاء رمز مميز للوصول إلى واجهة برمجة التطبيقات

انتقل إلى إعدادات المستخدم ← رموز الوصول واكتب الرمز المميز:

حساب لتلقي الرمز المميز
يتيح لك الوصول إلى واجهة برمجة التطبيقات فعل أي شيء تقريبًا مع مستودعاتك ، لذا أقترح عليك إنشاء حساب 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

نصيحة: استخدم linter لإجراء تغييرات على ملفات GitLab CI
حتى لو كنت تعمل بمفردك ، فإن العمل من خلال MR سيكون مساعدًا جيدًا ، حيث تقوم بتشغيل جميع التغييرات على ملفات خط الأنابيب من خلال linter. إذا ارتكبت خطأ في بناء جملة ملف YAML ، فلن يسمح لك ذلك بقطع مسار العمل ، ولكنه سيؤدي ببساطة إلى حظر الدمج.

مثال على حاويات تحتوي على نسالة يمكنك تضمينها في خط الأنابيب الخاص بك:

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

نحن نفعل MR ونضع علامة "كره".

في سجلات البناء:

الآن ضع "Like" وأعد فحصًا:

المصدر: www.habr.com