Gitlab CE இல் குறியீடு மதிப்பாய்வு: ஒன்றிணைப்பு கோரிக்கை ஒப்புதல்கள் இல்லை என்றால், ஆனால் நான் உண்மையில் விரும்புகிறேன்

GitLab இன் இலவச பதிப்பில் இல்லாத மிக அவசியமான செயல்பாடுகளில் ஒன்று, கட்டாய குறியீட்டு மதிப்பாய்வைப் பயன்படுத்தி களஞ்சியத்தை நீக்குவதற்கு எதிராக வாக்களிக்கும் திறன் மற்றும் ஒன்றிணைப்பு கோரிக்கையை (MR) கட்டுப்படுத்தும் திறன் ஆகும்.

குறைந்தபட்ச செயல்பாட்டை நாமே செய்வோம் - பல டெவலப்பர்கள் MR க்கு தம்ஸ் அப் கொடுக்கும் வரை ஒன்றிணைவதைத் தடைசெய்வோம்.

இது ஏன் அவசியம்?

எங்கள் நிறுவனம் ஒரு GitLab உரிமத்தை எளிதாக வாங்க முடியும். ஆனால், இணைய அணுகல் இல்லாமல் ஒரு மூடிய வளையத்தில் மேம்பாடு மேற்கொள்ளப்படுவதால், கடுமையான பட்ஜெட் திட்டமிடல் இருப்பதால், தேவையான செயல்பாட்டுடன் சுய நிர்வகிக்கப்பட்ட உரிமங்களை வாங்குவது பல மாதங்களுக்கு இழுக்கப்படலாம், ஆனால் இப்போது வேலை செய்யப்பட வேண்டும்.

இதன் விளைவாக நீங்கள் செய்ய வேண்டியது:

• அல்லது சில டெவலப்பர்களுக்கான பாதுகாக்கப்பட்ட கிளைகளில் ஒன்றிணைப்பதை முற்றிலும் தடைசெய்க, ஆனால் பின்னர் ஒன்றிணைக்க உரிமையுடைய டெவலப்பர்கள் மற்றவர்களின் MRகளை போனஸாக இணைக்கும்போது முரண்பாடுகளைப் பெறுகிறார்கள்;
• அல்லது நேற்றுதான் பணியமர்த்தப்பட்ட ஜூனியராக இருந்தாலும், குறியீடு மதிப்பாய்வு இல்லாமல் உங்கள் முதன்மைக் கிளையுடன் கட்டுப்பாடற்ற இணைப்புகளைச் செய்வதற்கான வாய்ப்பை வழங்கவும்.

நான் செய்த முதல் விஷயம் கூகிள், யாரோ ஒருவர் ஏற்கனவே இதேபோன்ற ஒன்றைச் செய்துள்ளார் என்று நம்புகிறார் (குறியீட்டை மாற்றாமல்), ஆனால் சமூக பதிப்பில் இதுவரை அத்தகைய செயலாக்கம் இல்லை என்று மாறியது.

வேலைக்கான பொதுவான திட்டம்

உதாரணமாக, சோதனைக் களஞ்சியத்தில் ஒன்றிணைக்கும் கோரிக்கை அனுமதிகளை உள்ளமைப்போம் myapp:

1. GitLab APIக்கான அணுகலுக்கான டோக்கனை உருவாக்குவோம் (அதன் மூலம் "க்கு" மற்றும் "எதிராக" வாக்குகளின் எண்ணிக்கை பற்றிய தகவலைப் பெறுவோம்)
2. GitLab மாறிகளில் டோக்கனைச் சேர்ப்போம்
3. பைப்லைனில் பிழைகள் ஏற்பட்டால் ஒன்றிணைப்பதை முடக்குவோம் (போதுமான வாக்குகள் இல்லை என்றால்)
4. CI/CD பைப்லைனின் ஒரு பகுதியாக வாக்கு சரிபார்ப்பை அமைப்போம்
5. பாதுகாக்கப்பட்ட கிளைகளுக்கு உறுதியளிப்பதை நாங்கள் தடைசெய்கிறோம்; அனைத்து மாற்றங்களும் MR மூலம் மட்டுமே செய்யப்படுகின்றன
6. இறுதியில் என்ன நடந்தது என்று பார்ப்போம்

1. API ஐ அணுக டோக்கனை உருவாக்கவும்

பயனர் அமைப்புகள் → அணுகல் டோக்கன்களுக்குச் சென்று டோக்கனை எழுதவும்:

டோக்கனைப் பெறுவதற்கான கணக்கு
ஏபிஐ அணுகல் உங்கள் களஞ்சியங்களுடன் கிட்டத்தட்ட எதையும் செய்ய உங்களை அனுமதிக்கிறது, எனவே ஒரு தனி Gitlab கணக்கை உருவாக்கவும், உங்கள் களஞ்சியங்களுக்கு (எ.கா. நிருபர்) குறைந்தபட்ச உரிமைகளை வழங்கவும் மற்றும் அந்தக் கணக்கிற்கான டோக்கனைப் பெறவும் பரிந்துரைக்கிறேன்.

2. கிட்லாப் மாறிகளில் டோக்கனைச் சேர்க்கவும்

எடுத்துக்காட்டாக, முந்தைய கட்டத்தில் நாங்கள் ஒரு டோக்கனைப் பெற்றோம் 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

உள்ளடக்கங்களை சரிபார்க்கவும்-அனுமதி.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