Gitlab CE मध्ये कोड पुनरावलोकन: विलीनीकरण विनंती मंजूर नसल्यास, परंतु मला खरोखर हवे आहे

सर्वात आवश्यक कार्यांपैकी एक, जे GitLab च्या विनामूल्य आवृत्तीमध्ये नाही, अनिवार्य कोड पुनरावलोकन वापरून, रेपॉजिटरी रद्दीकरण आणि नियंत्रण मर्ज विनंती (MR) विरुद्ध मत देण्याची क्षमता आहे.

चला किमान कार्यक्षमता स्वतः करूया - जोपर्यंत अनेक विकासक MR ला थम्स अप देत नाहीत तोपर्यंत आम्ही विलीन करण्यास मनाई करू.

हे अगदी आवश्यक का आहे?

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

परिणामी, तुम्हाला हे करावे लागेल:

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

मी Google ने पहिली गोष्ट केली, असा विश्वास होता की कोणीतरी आधीच असेच काहीतरी केले आहे (कोड सुधारित न करता), परंतु असे दिसून आले की समुदाय आवृत्तीमध्ये अद्याप अशी कोणतीही अंमलबजावणी नाही.

कामाची सामान्य योजना

उदाहरण म्हणून, चाचणी भांडारावर मर्ज विनंती मंजूरी कॉन्फिगर करूया myapp:

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

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


पडताळणी दरम्यान काय होते याबद्दल अधिक माहिती:

• मास्टर किंवा रिलीज/* शाखांमध्ये एमआर तयार करतानाच तपासणी केली जाईल असे बंधन आहे
• GitLab API वापरून, आम्हाला "लाइक्स" आणि "नापसंती" ची संख्या मिळते
• सकारात्मक आणि नकारात्मक प्रतिसादांमधील फरक मोजा
• जर फरक आम्ही NEED_VOTES मध्ये सेट केलेल्या मूल्यापेक्षा कमी असेल, तर आम्ही विलीन होण्याची क्षमता अवरोधित करतो

5. संरक्षित शाखांना प्रतिबंधित करा

आम्ही ज्या शाखांसाठी कोड पुनरावलोकने आयोजित करणे आवश्यक आहे ते आम्ही परिभाषित करतो आणि सूचित करतो की त्यांच्यासोबत फक्त MR द्वारे काम केले जाऊ शकते.

हे करण्यासाठी, सेटिंग्ज → रिपॉझिटरी → संरक्षित शाखांवर जा:

6. तपासा

NEED_VOTES सेट करा: 0

आम्ही MR बनवतो आणि "नापसंती" टाकतो.

बिल्ड लॉगमध्ये:

आता "लाइक" ठेवा आणि पुन्हा तपासणे सुरू करा:

स्त्रोत: www.habr.com