🥇 په ګیټلاب CE کې د کوډ بیاکتنه: که چیرې د ادغام غوښتنې تصویب شتون نلري ، مګر تاسو واقعیا غواړئ

یو له خورا اړینو دندو څخه ، کوم چې د GitLab وړیا نسخه کې ندي ، د لازمي کوډ بیاکتنې په کارولو سره د ذخیره کولو باطلولو او کنټرول ضمیمه غوښتنې (MR) پروړاندې د رایې ورکولو وړتیا ده.

راځئ چې لږترلږه فعالیت پخپله ترسره کړو - موږ به تر هغه پورې یوځای کول منع کړو تر څو چې ډیری پراختیا کونکي MR ته ګوتې پورته کړي.

ولې دا حتی اړین دی؟

زموږ اداره کولی شي په اسانۍ سره د GitLab جواز اخیستلو توان ولري. مګر، څرنګه چې پراختیا د انټرنیټ لاسرسي پرته په تړل شوي لوپ کې ترسره کیږي، او د بودیجې سخت پلان شتون لري، د اړین فعالیت سره د ځان اداره شوي جوازونو پیرود کولی شي د ډیرو میاشتو لپاره وګرځي، مګر اوس کار ته اړتیا لري.

د پایلې په توګه، تاسو باید:

یا د ځینو پراختیا کونکو لپاره په خوندي څانګو کې ادغام په بشپړ ډول منع کوي ، مګر بیا هغه پراختیا کونکي چې د ادغام حق لري د نورو خلکو MRs د بونس په توګه ضم کولو پرمهال شخړې ترلاسه کوي؛
یا دا فرصت ورکړئ چې د کوډ بیاکتنې پرته ستاسو د ماسټر څانګې سره غیر کنټرول شوي ادغام وکړي، حتی که دا جونیر وي، چې تیره ورځ ګمارل شوی و.

لومړی شی چې ما وکړل ګوګل و، په دې باور وو چې یو چا حتما دمخه ورته ورته کار کړی دی (پرته له دې چې کوډ بدل کړي)، مګر دا معلومه شوه چې د ټولنې په نسخه کې دا ډول تطبیق شتون نلري.

د کار عمومي سکیم

د مثال په توګه ، راځئ چې د ازموینې ذخیره کې د ضمیمه غوښتنې تصویبونه تنظیم کړو myapp:

راځئ چې د GitLab API ته د لاسرسي لپاره یوه نښه جوړه کړو (د دې له لارې به موږ د "لپاره" او "خلاف" د رایو شمیر په اړه معلومات ترلاسه کړو)
راځئ چې د GitLab متغیرونو ته نښه اضافه کړو
راځئ چې په پایپ لاین کې د غلطیو په صورت کې ادغام غیر فعال کړو (که چیرې کافي رایې شتون نلري)
راځئ چې د CI/CD پایپ لاین برخې په توګه د رایې تایید تنظیم کړو
موږ خوندي څانګو ته ژمنې کول منع کوو؛ ټول بدلونونه یوازې د MR له لارې رامینځته کیږي
راځئ وګورو چې په پای کې څه پیښ شوي

1. API ته د لاسرسي لپاره یوه نښه جوړه کړئ

د کارن ترتیباتو ته لاړ شئ → د لاسرسي ټوکن او نښه ولیکئ:

د نښه ترلاسه کولو لپاره حساب
د API لاسرسی تاسو ته اجازه درکوي ستاسو د ذخیره کولو سره نږدې هرڅه ترسره کړئ ، نو زه وړاندیز کوم چې یو جلا ګیتلاب حساب رامینځته کړئ ، دا ستاسو ذخیره کولو ته لږترلږه حقونه ورکړئ (د مثال په توګه راپور ورکوونکي) او د دې حساب لپاره نښه ترلاسه کړئ.

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 فایل په ترکیب کې تېروتنه وکړئ، نو دا به ستاسو د تولید پایپ لاین مات نه کړي، مګر په ساده ډول به ضم کول بند کړي.

د لینټرونو سره د کانټینرونو مثال چې تاسو کولی شئ خپل پایپ لاین کې جوړ کړئ:

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 جوړوو او "ناخوښ" کېږو.

د جوړونې په لوګو کې:

اوس "لکه" واچوئ او بیا چک کول پیل کړئ:

سرچینه: www.habr.com

په ګیټلاب CE کې د کوډ بیاکتنه: که چیرې د ادغام غوښتنې تصویب شتون ونلري ، مګر زه واقعیا غواړم