Gitlab CE માં કોડ સમીક્ષા: જો ત્યાં કોઈ મર્જ વિનંતી મંજૂરીઓ નથી, પરંતુ હું ખરેખર ઈચ્છું છું

GitLab ના ફ્રી વર્ઝનમાં ન હોય તેવી સૌથી જરૂરી સુવિધાઓમાંની એક ફરજિયાત કોડ સમીક્ષાનો ઉપયોગ કરીને મર્જ વિનંતી (MR) ને નિયંત્રિત કરવા માટે રિપોઝીટરીને શૂન્ય કરવા સામે મત આપવાની ક્ષમતા છે.

અમે ન્યૂનતમ કાર્યક્ષમતા જાતે કરીશું - જ્યાં સુધી ઘણા વિકાસકર્તાઓ MR ને "થમ્બ્સ અપ" ન આપે ત્યાં સુધી અમે મર્જને અક્ષમ કરીશું.

આ બધું કેમ છે?

અમારી સંસ્થા GitLab લાઇસન્સ ખરીદવાનું પરવડી શકે છે. પરંતુ, કારણ કે વિકાસ ઇન્ટરનેટની ઍક્સેસ વિના બંધ લૂપમાં કરવામાં આવે છે, અને એક કડક બજેટ આયોજન છે, જરૂરી કાર્યક્ષમતા સાથે સ્વ-સંચાલિત લાઇસન્સ ખરીદવામાં ઘણા મહિનાઓ લાગી શકે છે, અને તમારે હવે કામ કરવાની જરૂર છે.

પરિણામે, તમારે આ કરવું પડશે:

• અથવા કેટલાક વિકાસકર્તાઓ માટે સંરક્ષિત શાખાઓમાં મર્જ કરવા પર સંપૂર્ણપણે પ્રતિબંધ મૂકે છે, પરંતુ પછી જે વિકાસકર્તાઓને મર્જ કરવાનો અધિકાર છે તેઓ અન્ય લોકોના એમઆરને બોનસ તરીકે મર્જ કરતી વખતે તકરાર મેળવે છે;
• અથવા તમને કોડ રિવ્યૂ વિના તમારી માસ્ટર બ્રાન્ચ સાથે અનિયંત્રિત મર્જ કરવાની મંજૂરી આપે છે, પછી ભલે તે જુનિયર હોય જે ગઈકાલે જ સ્થાયી થયો હોય.

પ્રથમ વસ્તુ મેં ગૂગલ પર જઈને કર્યું, એવું માનીને કે કોઈએ પહેલેથી જ કંઈક આવું જ કર્યું છે (કોડ રિફાઇન કર્યા વિના), પરંતુ તે બહાર આવ્યું છે કે સમુદાય સંસ્કરણમાં હજી સુધી આવું કોઈ અમલીકરણ નથી.

કાર્યની સામાન્ય યોજના

ઉદાહરણ તરીકે, ચાલો ટેસ્ટ રિપોઝીટરી પર મર્જ વિનંતી મંજૂરીઓ સેટ કરીએ 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/.*$/'


તપાસ કરતી વખતે શું થાય છે તે વિશે વધુ જાણો:

• પ્રતિબંધ સેટ કરવામાં આવ્યો છે કે ચેક માત્ર ત્યારે જ થશે જ્યારે માસ્ટર અથવા રીલીઝ /* શાખાઓમાં MR બનાવશો
• GitLab API નો ઉપયોગ કરીને, "પસંદ" અને "નાપસંદ" ની સંખ્યા મેળવો
• હકારાત્મક અને નકારાત્મક પ્રતિભાવો વચ્ચેના તફાવતની ગણતરી કરો
• જો તફાવત અમે NEED_VOTES માં સેટ કરેલ મૂલ્ય કરતા ઓછો હોય, તો અમે મર્જ કરવાની ક્ષમતાને અવરોધિત કરીએ છીએ

5. સંરક્ષિત શાખાઓ માટે કમિટ્સને અક્ષમ કરો

અમે તે શાખાઓ નિર્ધારિત કરીએ છીએ કે જેના માટે અમારે કોડ સમીક્ષા કરવી જોઈએ અને સૂચવીએ છીએ કે તેમની સાથે ફક્ત MR દ્વારા જ કામ કરી શકાય છે.

આ કરવા માટે, સેટિંગ્સ → રિપોઝીટરી → સંરક્ષિત શાખાઓ પર જાઓ:

6. તપાસી રહ્યું છે

NEED_VOTES સેટ કરો: 0

અમે MR કરીએ છીએ અને "નાપસંદ" મૂકીએ છીએ.

બિલ્ડ લોગમાં:

હવે "લાઇક" મૂકો અને ફરીથી તપાસ ચલાવો:

સોર્સ: www.habr.com