Gitlab CE-യിലെ കോഡ് അവലോകനം: ലയന അഭ്യർത്ഥന അംഗീകാരങ്ങൾ ഇല്ലെങ്കിൽ, പക്ഷേ എനിക്ക് ശരിക്കും വേണം

GitLab-ന്റെ സൗജന്യ പതിപ്പിൽ ഇല്ലാത്ത ഏറ്റവും ആവശ്യമായ ഫംഗ്‌ഷനുകളിൽ ഒന്ന്, നിർബന്ധിത കോഡ് അവലോകനം ഉപയോഗിച്ച് റിപ്പോസിറ്ററി അസാധുവാക്കലിനെതിരെ വോട്ടുചെയ്യാനും ലയിപ്പിക്കാനുള്ള അഭ്യർത്ഥന (MR) നിയന്ത്രിക്കാനുമുള്ള കഴിവാണ്.

ഏറ്റവും കുറഞ്ഞ പ്രവർത്തനക്ഷമത നമുക്ക് സ്വയം ചെയ്യാം - നിരവധി ഡെവലപ്പർമാർ MR-ന് തംബ്സ് അപ്പ് നൽകുന്നത് വരെ ഞങ്ങൾ ലയിക്കുന്നത് നിരോധിക്കും.

എന്തുകൊണ്ടാണ് ഇത് പോലും ആവശ്യമായി വരുന്നത്?

ഒരു GitLab ലൈസൻസ് വാങ്ങാൻ ഞങ്ങളുടെ സ്ഥാപനത്തിന് എളുപ്പത്തിൽ കഴിയും. പക്ഷേ, ഇൻറർനെറ്റ് ആക്‌സസ് ഇല്ലാതെ ഒരു അടച്ച ലൂപ്പിലാണ് വികസനം നടക്കുന്നത്, കൂടാതെ കർശനമായ ബജറ്റ് ആസൂത്രണം ഉള്ളതിനാൽ, ആവശ്യമായ പ്രവർത്തനക്ഷമതയുള്ള സ്വയം നിയന്ത്രിത ലൈസൻസുകൾ വാങ്ങുന്നത് മാസങ്ങളോളം വലിച്ചിടാം, പക്ഷേ ഇപ്പോൾ ജോലി ചെയ്യേണ്ടതുണ്ട്.

ഫലമായി നിങ്ങൾ ചെയ്യേണ്ടത്:

• അല്ലെങ്കിൽ ചില ഡെവലപ്പർമാർക്കായി സംരക്ഷിത ശാഖകളിൽ ലയിപ്പിക്കുന്നത് പൂർണ്ണമായും നിരോധിക്കുക, എന്നാൽ പിന്നീട് ലയിപ്പിക്കാനുള്ള അവകാശമുള്ള ഡെവലപ്പർമാർക്ക് മറ്റ് ആളുകളുടെ MR-കൾ ബോണസായി ലയിപ്പിക്കുമ്പോൾ വൈരുദ്ധ്യങ്ങൾ ലഭിക്കും;
• അല്ലെങ്കിൽ കോഡ് അവലോകനം കൂടാതെ നിങ്ങളുടെ മാസ്റ്റർ ബ്രാഞ്ചുമായി അനിയന്ത്രിതമായ ലയനങ്ങൾ നടത്താനുള്ള അവസരം നൽകുക, അത് ഇന്നലെ ജോലിക്കെടുത്ത ജൂനിയർ ആണെങ്കിലും.

ഞാൻ ആദ്യം ചെയ്തത് Google ആണ്, ആരെങ്കിലും തീർച്ചയായും സമാനമായ എന്തെങ്കിലും (കോഡ് പരിഷ്‌ക്കരിക്കാതെ) ഇതിനകം ചെയ്തിട്ടുണ്ടെന്ന് വിശ്വസിച്ചു, എന്നാൽ കമ്മ്യൂണിറ്റി പതിപ്പിൽ ഇതുവരെ അത്തരം നടപ്പാക്കൽ ഇല്ലെന്ന് മനസ്സിലായി.

ജോലിയുടെ പൊതു പദ്ധതി

ഒരു ഉദാഹരണമായി, ഒരു ടെസ്റ്റ് റിപ്പോസിറ്ററിയിൽ ലയന അഭ്യർത്ഥന അംഗീകാരങ്ങൾ കോൺഫിഗർ ചെയ്യാം 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. കോഡ് അവലോകനത്തിന് ശേഷം സഹപ്രവർത്തകരുടെ അംഗീകാരം ലഭിച്ചില്ലെങ്കിൽ ഞങ്ങൾ ലയനത്തിന് നിരോധനം ഏർപ്പെടുത്തും.

ഞങ്ങളുടെ കാര്യത്തിൽ, മതിയായ വോട്ടുകൾ ഇല്ലെങ്കിൽ അസംബ്ലി പൈപ്പ്ലൈൻ ഒരു പിശക് നൽകും എന്നതാണ് ലയന നിരോധനം.

ക്രമീകരണങ്ങൾ → പൊതുവായ → അഭ്യർത്ഥനകൾ ലയിപ്പിക്കുക → പരിശോധനകൾ ലയിപ്പിക്കുക എന്നതിലേക്ക് പോയി അസംബ്ലി ലൈനുകൾ വിജയകരമായി പൂർത്തിയാക്കേണ്ട ഓപ്ഷൻ പ്രവർത്തനക്ഷമമാക്കുക.

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 - ക്രമീകരണങ്ങൾ - 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 ഉണ്ടായിരിക്കണമെന്ന് നിർണ്ണയിക്കുന്നു. ഒന്നിന് തുല്യമായ മൂല്യം അർത്ഥമാക്കുന്നത് "ഇഷ്‌ടപ്പെടുക" വഴി നിങ്ങൾക്ക് തന്നെ നിങ്ങളുടെ എംആർ അംഗീകരിക്കാൻ കഴിയും എന്നാണ്.

ടെസ്റ്റ് ഘട്ടം ഉൾപ്പെടുന്നു, അത് "ലൈക്കുകളുടെ" എണ്ണം പരിശോധിക്കുന്നു.

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 മുഖേന മാത്രമേ പ്രവർത്തിക്കാനാകൂ എന്ന് സൂചിപ്പിക്കുകയും ചെയ്യുന്നു.

ഇത് ചെയ്യുന്നതിന്, ക്രമീകരണങ്ങൾ → റിപ്പോസിറ്ററി → സംരക്ഷിത ശാഖകൾ എന്നതിലേക്ക് പോകുക:

6. പരിശോധിക്കുക

NEED_VOTES സജ്ജമാക്കുക: 0

ഞങ്ങൾ ഒരു MR ഉണ്ടാക്കി "ഡിസ്‌ലൈക്ക്" ഇടുന്നു.

ബിൽഡ് ലോഗുകളിൽ:

ഇപ്പോൾ "ലൈക്ക്" ഇട്ടു വീണ്ടും പരിശോധിക്കാൻ ആരംഭിക്കുക:

അവലംബം: www.habr.com