Gitlab CE හි කේත සමාලෝචනය: ඒකාබද්ධ ඉල්ලීම් අනුමත කිරීම් නොමැති නම්, නමුත් මට ඇත්තටම අවශ්‍යයි

GitLab හි නිදහස් අනුවාදයේ නොමැති වඩාත්ම අවශ්‍ය කාර්යයක් නම්, අනිවාර්ය කේත සමාලෝචනය භාවිතා කරමින් ගබඩා ශුන්‍ය කිරීමට එරෙහිව ඡන්දය දීමට සහ ඒකාබද්ධ ඉල්ලීම (MR) පාලනය කිරීමට ඇති හැකියාවයි.

අපි අවම ක්‍රියාකාරීත්වය අප විසින්ම කරමු - සංවර්ධකයින් කිහිප දෙනෙකු MR වෙත ඇඟිල්ල දිගු කරන තෙක් අපි ඒකාබද්ධ කිරීම තහනම් කරන්නෙමු.

මෙය පවා අවශ්ය වන්නේ ඇයි?

අපගේ සංවිධානයට පහසුවෙන් GitLab බලපත්‍රයක් මිලදී ගත හැකිය. එහෙත්, අන්තර්ජාල ප්රවේශය නොමැතිව සංවෘත ලූපයක් තුළ සංවර්ධනය සිදු කරනු ලබන අතර, දැඩි අයවැය සැලසුම් කිරීමක් ඇති බැවින්, අවශ්ය ක්රියාකාරිත්වය සහිත ස්වයං-කළමනාකරණ බලපත්ර මිලදී ගැනීම මාස ගණනාවක් ඇදගෙන යා හැකි නමුත්, දැන් වැඩ කළ යුතුය.

ප්රතිඵලයක් වශයෙන්, ඔබ කළ යුත්තේ:

• හෝ සමහර සංවර්ධකයින් සඳහා ආරක්ෂිත ශාඛාවල ඒකාබද්ධ කිරීම සම්පූර්ණයෙන්ම තහනම් කරන්න, නමුත් පසුව ඒකාබද්ධ කිරීමට අයිතිය ඇති සංවර්ධකයින්ට ප්‍රසාද දීමනාවක් ලෙස වෙනත් පුද්ගලයින්ගේ MR ඒකාබද්ධ කිරීමේදී ගැටුම් ඇති වේ;
• හෝ කේත සමාලෝචනයකින් තොරව ඔබේ ප්‍රධාන ශාඛාව සමඟ පාලනයකින් තොරව ඒකාබද්ධ වීමට අවස්ථාව ලබා දෙන්න, එය ඊයේ කුලියට ගත් ජූනියර් වුවද.

මා කළ පළමු දෙය නම් ගූගල් ය, යමෙකු නියත වශයෙන්ම දැනටමත් සමාන දෙයක් කර ඇති බව විශ්වාස කරයි (කේතය වෙනස් නොකර), නමුත් ප්‍රජා අනුවාදයේ තවමත් එවැනි ක්‍රියාත්මක කිරීමක් නොමැති බව පෙනී ගියේය.

වැඩ කිරීමේ පොදු යෝජනා ක්රමය

උදාහරණයක් ලෙස, පරීක්ෂණ ගබඩාවක ඒකාබද්ධ ඉල්ලීම් අනුමත කිරීම් වින්‍යාස කරමු myapp:

1. GitLab API වෙත ප්‍රවේශය සඳහා ටෝකනයක් නිර්මාණය කරමු (එය හරහා "සඳහා" සහ "විරුද්ධව" ඡන්ද සංඛ්‍යාව පිළිබඳ තොරතුරු අපට ලැබෙනු ඇත)
2. GitLab විචල්‍ය වලට ටෝකනය එකතු කරමු
3. නල මාර්ගයේ දෝෂ ඇති වුවහොත් ඒකාබද්ධ කිරීම අක්‍රිය කරමු (ප්‍රමාණවත් තරම් ඉහළ ඡන්ද නොමැති නම්)
4. CI/CD නල මාර්ගයේ කොටසක් ලෙස ඡන්ද සත්‍යාපනය සකසමු
5. ආරක්ෂිත ශාඛා සඳහා කැපවීම් කිරීම අපි තහනම් කරමු; සියලුම වෙනස්කම් සිදු කරනු ලබන්නේ MR හරහා පමණි
6. අවසානයේ සිදුවූයේ කුමක්දැයි සොයා බලමු

1. API වෙත ප්‍රවේශ වීමට ටෝකනයක් සාදන්න

පරිශීලක සැකසීම් → ප්‍රවේශ ටෝකන වෙත ගොස් ටෝකනය ලියන්න:

ටෝකනයක් ලබා ගැනීමට ගිණුම
API ප්‍රවේශය ඔබට ඔබගේ ගබඩාවන් සමඟ ඕනෑම දෙයක් කිරීමට ඉඩ සලසයි, එබැවින් මම වෙනම Gitlab ගිණුමක් සෑදීමට නිර්දේශ කරමි, එයට ඔබගේ ගබඩාවලට අවම අයිතිවාසිකම් ලබා දීම (උදා: වාර්තාකරු) සහ එම ගිණුම සඳහා ටෝකනයක් ලබා ගැනීම.

2. Gitlab විචල්‍ය වලට ටෝකනය එක් කරන්න

උදාහරණයක් ලෙස, පෙර පියවරේදී අපට ටෝකනයක් ලැබුණි QmN2Y0NOUFlfeXhvd21ZS01aQzgK

විවෘත සැකසුම් → CI/CD → විචල්‍යයන් → විචල්‍ය එක් කරන්න → GITLAB_TOKEN_FOR_CI

ප්රතිඵලයක් වශයෙන් අපට ලැබෙන්නේ:

මෙය එක් ගබඩාවක හෝ ගබඩා සමූහයක සිදු කළ හැක.

3. කේත සමාලෝචනයෙන් පසු සගයන්ගේ අනුමැතිය නොලැබුනේ නම් අපි ඒකාබද්ධ කිරීම තහනම් කරමු.

අපගේ නඩුවේදී, ඒකාබද්ධ කිරීම තහනම් කිරීම ප්‍රමාණවත් ඡන්ද නොමැති නම් එකලස් කිරීමේ නල මාර්ගය දෝෂයක් ඇති කරයි.

Settings → General → Merge Requests → Merge Checks වෙත ගොස් එකලස් කිරීමේ රේඛා සාර්ථකව සම්පූර්ණ කළ යුතු විකල්පය සක්‍රීය කරන්න.

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 repository - Settings - CI/CD - Assembly lines - Custom CI configuration path - වෙත යාමෙන් නව නල මාර්ග ගොනුවේ ස්ථානය සඳහන් කිරීමට අවශ්‍ය වනු ඇත - නව ගොනුව සඳහන් කරන්න, උදා. 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 හට Merge ලබා ගැනීමට කොපමණ “thumbs up” තිබිය යුතුද යන්න තීරණය කරයි. එකකට සමාන අගයක් යනු ඔබට ඔබේ 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/.*$/'


සත්‍යාපනය අතරතුර සිදුවන දේ පිළිබඳ වැඩි විස්තර:

• මාස්ටර් හෝ රිලීස්/* ශාඛාවල MR නිර්මාණය කිරීමේදී පමණක් පරීක්ෂාව සිදු කරනු ලබන බවට සීමාවක් තිබේ
• GitLab API භාවිතයෙන්, අපි "කැමති" සහ "අකැමති" ගණන ලබා ගනිමු.
• ධනාත්මක සහ ඍණාත්මක ප්රතිචාර අතර වෙනස ගණනය කරන්න
• වෙනස අප NEED_VOTES හි සකසන අගයට වඩා අඩු නම්, අපි ඒකාබද්ධ කිරීමේ හැකියාව අවහිර කරමු

5. ආරක්ෂිත ශාඛාවලට බැඳීම් තහනම් කිරීම

අපි කේත සමාලෝචන පැවැත්විය යුතු ශාඛා නිර්වචනය කර ඒවා MR හරහා පමණක් වැඩ කළ හැකි බව පෙන්නුම් කරමු.

මෙය සිදු කිරීම සඳහා, Settings → Repository → Protected Branches වෙත යන්න:

6. පරීක්ෂා කරන්න

NEED_VOTES සකසන්න: 0

අපි MR එකක් හදලා "අකමැත්ත" දානවා.

ගොඩනැගීමේ ලඝු-සටහන් තුළ:

දැන් "like" දමා නැවත පරීක්ෂා කිරීම ආරම්භ කරන්න:

මූලාශ්රය: www.habr.com