🥇 ڪوڊ جو جائزو Gitlab CE ۾: جيڪڏهن ڪو به ضم ڪرڻ جي درخواست جي منظوري نه آهي، پر توهان واقعي چاهيو ٿا

هڪ تمام ضروري ڪم، جيڪو GitLab جي مفت ورزن ۾ نه آهي، لازمي ڪوڊ جائزو استعمال ڪندي، مخزن جي منسوخي ۽ ڪنٽرول ضم ڪرڻ جي درخواست (MR) جي خلاف ووٽ ڏيڻ جي صلاحيت آهي.

اچو ته گھٽ ۾ گھٽ ڪارڪردگي پاڻ ڪريون - اسان ضم ڪرڻ کان منع ڪنداسين جيستائين ڪيترائي ڊولپرز MR کي انگوٹھا نه ڏين.

اهو ڇو ضروري آهي؟

اسان جي تنظيم آساني سان GitLab لائسنس خريد ڪرڻ جي متحمل ٿي سگهي ٿي. پر، جيئن ته ترقي انٽرنيٽ جي رسائي جي بغير بند ٿيل لوپ ۾ ڪئي وئي آهي، ۽ سخت بجيٽ پلاننگ آهي، ضروري ڪارڪردگي سان خود منظم ٿيل لائسنس جي خريداري ڪيترن ئي مهينن تائين ڇڪي سگهي ٿي، پر ڪم ڪرڻ جي ضرورت آهي هاڻي.

نتيجي طور، توھان کي ڪرڻو پوندو:

يا ڪجهه ڊولپرز لاءِ محفوظ شاخن ۾ ضم ٿيڻ کي مڪمل طور تي منع ڪري ٿو، پر پوءِ ڊولپرز جن کي ضم ڪرڻ جو حق آهي، انهن کي ٻين ماڻهن جي ايم آرز کي بونس طور ضم ڪرڻ وقت تڪرار پيدا ٿئي ٿو؛
يا ڪوڊ جي نظرثاني کان سواءِ پنهنجي ماسٽر برانچ سان بي ضابطگي سان ضم ڪرڻ جو موقعو ڏيو، توڙي جو اهو جونيئر هجي، جنهن کي ڪالهه ئي ڀرتي ڪيو ويو هو.

پهرين شيء جيڪا مون ڪئي هئي اها گوگل هئي، اهو يقين آهي ته ڪنهن ماڻهو ضرور اڳ ۾ ئي ڪجهه ڪيو آهي (ڪوڊ کي تبديل ڪرڻ کان سواء)، پر اهو ظاهر ٿيو ته ڪميونٽي ورزن ۾ اڃا تائين ڪو به عمل ناهي.

ڪم جي عام منصوبي

مثال طور، اچو ته ترتيب ڏيو ضم ڪرڻ جي درخواست جي منظورين کي ٽيسٽ مخزن تي myapp:

اچو ته GitLab API تائين رسائي لاءِ هڪ ٽوڪن ٺاهيو (ان جي ذريعي اسان "لاء" ۽ "خلاف" ووٽن جي تعداد بابت معلومات حاصل ڪنداسين)
اچو ته ٽوڪن کي GitLab متغير ۾ شامل ڪريون
اچو ته پائپ لائن ۾ غلطين جي صورت ۾ ضم کي بند ڪريون (جيڪڏهن ڪافي ووٽ نه آهن)
اچو ته سيٽ اپ ڪريون ووٽ جي تصديق کي CI/CD پائپ لائن جي حصي طور
اسان محفوظ شاخن تي ڪم ڪرڻ کان منع ڪريون ٿا؛ سڀ تبديليون صرف ايم آر ذريعي ڪيون وينديون آهن
اچو ته ڏسو ته آخر ۾ ڇا ٿيو

1. API تائين رسائي حاصل ڪرڻ لاءِ ٽوڪن ٺاهيو

يوزر سيٽنگز ڏانھن وڃو → ٽوڪن تائين رسائي ڪريو ۽ ٽوڪن کي لکو:

هڪ ٽوڪن حاصل ڪرڻ لاء اڪائونٽ
API جي رسائي توهان کي توهان جي ذخيرن سان لڳ ڀڳ ڪجھ به ڪرڻ جي اجازت ڏئي ٿي، تنهنڪري مان هڪ الڳ Gitlab اڪائونٽ ٺاهڻ جي صلاح ڏيان ٿو، ان کي توهان جي ذخيرن کي گهٽ ۾ گهٽ حق ڏيو (مثال طور رپورٽر) ۽ انهي اڪائونٽ لاءِ ٽوڪن حاصل ڪريو.

2. ٽوڪن شامل ڪريو Gitlab variables ۾

مثال طور، پوئين قدم ۾ اسان هڪ ٽوڪن حاصل ڪيو QmN2Y0NOUFlfeXhvd21ZS01aQzgK

کوليو سيٽنگون → CI/CD → Variables → Add variable → 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 فائل جي نحو ۾ غلطي ڪريو ٿا، اهو توهان جي پيداوار جي پائپ لائن کي ٽوڙي نه سگهندو، پر صرف ضم کي بلاڪ ڪندو.

لينٽرن سان ڪنٽينرز جو ھڪڙو مثال جيڪو توھان پنھنجي پائپ لائن ۾ ٺاھي سگھو ٿا:

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 وٽ لازمي آهي ته ضم ٿيڻ لاءِ. هڪ جي برابر قدر جو مطلب اهو آهي ته توهان پاڻ پنهنجي ايم آر کي ”پسند“ ڪندي ان کي منظور ڪري سگهو ٿا.

شامل ڪريو ٽيسٽ اسٽيج، جيڪو "پسند" جو تعداد چيڪ ڪري ٿو.

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

مواد چيڪ-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/.*$/'

تصديق جي دوران ڇا ٿئي ٿو بابت وڌيڪ معلومات:

اتي هڪ پابندي آهي ته چيڪ صرف ان وقت ڪيو ويندو جڏهن ماسٽر يا رليز/* برانچز ۾ ايم آر ٺاهي
GitLab API استعمال ڪندي، اسان "پسند" ۽ "ناپسند" جو تعداد حاصل ڪندا آهيون
مثبت ۽ منفي جوابن جي وچ ۾ فرق جو اندازو لڳايو
جيڪڏهن فرق ان قدر کان گهٽ آهي جيڪو اسان NEED_VOTES ۾ مقرر ڪيو آهي، ته پوءِ اسان ضم ڪرڻ جي صلاحيت کي روڪيون ٿا

5. حفاظتي شاخن کي پابند ڪرڻ

اسان انهن شاخن جي وضاحت ڪريون ٿا جن لاءِ اسان کي ڪوڊ جائزو وٺڻ گهرجي ۽ ظاهر ڪيو وڃي ته انهن سان صرف MR ذريعي ڪم ڪري سگهجي ٿو.

ائين ڪرڻ لاءِ، وڃو سيٽنگون → مخزن → محفوظ ٿيل شاخون:

6. چيڪ ڪريو

سيٽ ڪريو NEED_VOTES: 0

اسان هڪ ايم آر ٺاهيو ۽ "ناپسند" رکون ٿا.

تعمير جي لاگن ۾:

ھاڻي وجھو "پسند" ۽ ٻيهر چيڪ ڪرڻ شروع ڪريو:

جو ذريعو: www.habr.com

Gitlab CE ۾ ڪوڊ جو جائزو: جيڪڏهن ڪو ضم ڪرڻ جي درخواست جي منظوري نه آهي، پر مان واقعي چاهيان ٿو