Gitlab CE मा कोड समीक्षा: यदि त्यहाँ कुनै मर्ज अनुरोध अनुमोदन छैन, तर म वास्तवमै चाहन्छु

सबैभन्दा आवश्यक कार्यहरू मध्ये एक, जुन GitLab को नि: शुल्क संस्करणमा छैन, अनिवार्य कोड समीक्षा प्रयोग गरी रिपोजिटरी रद्दीकरण र नियन्त्रण मर्ज अनुरोध (MR) विरुद्ध मतदान गर्ने क्षमता हो।

न्यूनतम कार्यक्षमता आफैं गरौं - धेरै विकासकर्ताहरूले MR लाई थम्ब्स अप नगरेसम्म हामी मर्जलाई निषेध गर्नेछौं।

यो पनि किन आवश्यक छ?

हाम्रो संगठनले सजिलैसँग GitLab लाइसेन्स किन्न सक्नेछ। तर, विकास इन्टरनेट पहुँच बिना नै बन्द लुपमा गरिन्छ, र कडा बजेट योजना छ, आवश्यक कार्यक्षमता सहित स्व-व्यवस्थित इजाजतपत्रहरूको खरीद धेरै महिनासम्म तान्न सक्छ, तर काम अब गर्न आवश्यक छ।

नतिजाको रूपमा तपाईले गर्नु पर्छ:

• वा केही विकासकर्ताहरूको लागि संरक्षित शाखाहरूमा मर्जलाई पूर्ण रूपमा निषेध गर्नुहोस्, तर त्यसपछि मर्ज गर्ने अधिकार भएका विकासकर्ताहरूले बोनसको रूपमा अन्य व्यक्तिको एमआरहरू मर्ज गर्दा विवादहरू प्राप्त गर्छन्;
• वा कोड समीक्षा बिना नै आफ्नो मास्टर शाखासँग अनियन्त्रित मर्ज गर्ने मौका दिनुहोस्, चाहे त्यो जुनियर होस्, जसलाई हिजो भर्खरै भर्ना गरिएको थियो।

मैले गरेको पहिलो कुरा गुगल थियो, विश्वास गर्दै कि कसैले पक्कै पनि यस्तै केहि गरिसकेको छ (कोड परिमार्जन नगरीकन), तर यो सामुदायिक संस्करणमा त्यस्तो कुनै कार्यान्वयन भएको छैन।

कार्यको सामान्य योजना

उदाहरणको रूपमा, परीक्षण भण्डारमा मर्ज अनुरोध अनुमोदनहरू कन्फिगर गरौं myapp:

1. GitLab API मा पहुँचको लागि टोकन सिर्जना गरौं (यसको माध्यमबाट हामीले "का लागि" र "विपरीत" भोटहरूको संख्याको बारेमा जानकारी प्राप्त गर्नेछौं)
2. GitLab चरहरूमा टोकन थपौं
3. पाइपलाइनमा त्रुटिहरू भएमा मर्जलाई असक्षम गरौं (यदि पर्याप्त अपभोटहरू छैनन् भने)
4. CI/CD पाइपलाइनको भागको रूपमा भोट प्रमाणीकरण सेट अप गरौं
5. हामी संरक्षित शाखाहरूमा प्रतिबद्धताहरू गर्न निषेध गर्छौं; सबै परिवर्तनहरू MR मार्फत मात्र गरिन्छ
6. अन्तमा के भयो जाँच गरौं

1. API पहुँच गर्न टोकन सिर्जना गर्नुहोस्

प्रयोगकर्ता सेटिङहरूमा जानुहोस् → टोकनहरू पहुँच गर्नुहोस् र टोकन लेख्नुहोस्:

टोकन प्राप्त गर्न खाता
एपीआई पहुँचले तपाइँलाई तपाइँको रिपोजिटरीहरु संग लगभग केहि गर्न को लागी अनुमति दिन्छ, त्यसैले म एक अलग Gitlab खाता बनाउन को लागी सिफारिस गर्दछु, यसलाई तपाइँको भण्डारहरु (जस्तै रिपोर्टर) लाई न्यूनतम अधिकार दिदै र त्यो खाताको लागि टोकन प्राप्त गर्नुहोस्।

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 फाइलहरूमा परिवर्तनहरू गर्न एक linter प्रयोग गर्नुहोस्
यदि तपाइँ एक्लै काम गर्नुहुन्छ भने, MR मार्फत काम गर्नु राम्रो मद्दत हुनेछ, तपाइँका सबै परिवर्तनहरू पाइपलाइन फाइलहरूमा लिन्टर मार्फत चलाउनु हो। यदि तपाईंले YAML फाइलको सिन्ट्याक्समा गल्ती गर्नुभयो भने, यसले तपाईंको उत्पादन पाइपलाइन तोड्ने छैन, तर मर्जलाई मात्र रोक्नेछ।

तपाईंले आफ्नो पाइपलाइनमा निर्माण गर्न सक्ने linters भएका कन्टेनरहरूको उदाहरण:

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/.*$/'


प्रमाणीकरणको क्रममा के हुन्छ भन्ने बारे थप जानकारी:

• मास्टर वा रिलिज/* शाखाहरूमा एमआर सिर्जना गर्दा मात्र जाँच गरिनेछ भन्ने प्रतिबन्ध छ
• GitLab API प्रयोग गरेर, हामीले "लाइक" र "डिसलाइक" को संख्या पाउँछौं
• सकारात्मक र नकारात्मक प्रतिक्रियाहरू बीचको भिन्नता गणना गर्नुहोस्
• यदि भिन्नता हामीले NEED_VOTES मा सेट गरेको मान भन्दा कम छ भने, हामी मर्ज गर्ने क्षमतालाई रोक्छौं।

5. संरक्षित शाखाहरूमा प्रतिबद्धता निषेध गर्नुहोस्

हामी शाखाहरू परिभाषित गर्छौं जसको लागि हामीले कोड समीक्षाहरू सञ्चालन गर्नुपर्छ र तिनीहरू MR मार्फत मात्र काम गर्न सकिन्छ भनेर संकेत गर्छौं।

यो गर्नको लागि, सेटिंग्स → रिपोजिटरी → संरक्षित शाखाहरूमा जानुहोस्:

6. जाँच गर्नुहोस्

NEED_VOTES: ० सेट गर्नुहोस्

हामी एमआर बनाउँछौं र "डिसलाइक" राख्छौं।

निर्माण लगहरूमा:

अब "लाइक" राख्नुहोस् र फेरि जाँच सुरु गर्नुहोस्:

स्रोत: www.habr.com