კოდის განხილვა Gitlab CE-ში: თუ არ არის შერწყმის მოთხოვნის დამტკიცება, მაგრამ მე ნამდვილად მინდა

ერთ-ერთი ყველაზე აუცილებელი ფუნქცია, რომელიც არ არის GitLab-ის უფასო ვერსიაში, არის საცავების გაუქმების წინააღმდეგ ხმის მიცემის შესაძლებლობა და შერწყმის მოთხოვნის (MR) კონტროლი, კოდის სავალდებულო განხილვის გამოყენებით.

მოდით გავაკეთოთ მინიმალური ფუნქციონირება ჩვენ თვითონ - ჩვენ ავკრძალავთ Merge-ს მანამ, სანამ რამდენიმე დეველოპერი MR-ს არ დაეთანხმება.

რატომ არის ეს საერთოდ საჭირო?

ჩვენს ორგანიზაციას შეუძლია ადვილად შეიძინოს GitLab ლიცენზია. მაგრამ, რადგან განვითარება ხორციელდება დახურულ მარყუჟში ინტერნეტით წვდომის გარეშე და არსებობს მკაცრი ბიუჯეტის დაგეგმვა, საჭირო ფუნქციონირებით თვითმართვადი ლიცენზიების შეძენა შეიძლება მრავალი თვის განმავლობაში გაგრძელდეს, მაგრამ სამუშაო ახლა უნდა გაკეთდეს.

შედეგად თქვენ უნდა:

• ან მთლიანად აკრძალოს შერწყმა დაცულ ფილიალებში ზოგიერთი დეველოპერისთვის, მაგრამ შემდეგ დეველოპერები, რომლებსაც აქვთ შერწყმის უფლება, იღებენ კონფლიქტებს სხვა ადამიანების MR-ების გაერთიანებისას ბონუსად;
• ან მიეცით შესაძლებლობა, განახორციელოთ უკონტროლო შერწყმა თქვენს მთავარ ფილიალთან კოდის განხილვის გარეშე, თუნდაც ეს იყოს უმცროსი, რომელიც გუშინ დაქირავებული იყო.

პირველი, რაც გავაკეთე, იყო Google, მჯერა, რომ ვიღაცას ნამდვილად ჰქონდა მსგავსი რამ (კოდის შეცვლის გარეშე), მაგრამ აღმოჩნდა, რომ საზოგადოების ვერსიაში ასეთი განხორციელება ჯერ არ ყოფილა.

მუშაობის ზოგადი სქემა

მაგალითად, მოდით დავაკონფიგურიროთ Merge-ის მოთხოვნის დამტკიცებები სატესტო საცავზე myapp:

1. მოდით შევქმნათ ჟეტონი GitLab API-ზე წვდომისთვის (მისი მეშვეობით მივიღებთ ინფორმაციას „მომხრე“ და „წინააღმდეგ“ ხმების რაოდენობის შესახებ)
2. მოდით დავამატოთ ჟეტონი GitLab ცვლადებს
3. მოდით გამორთოთ შერწყმა მილსადენში შეცდომის შემთხვევაში (თუ საკმარისი ხმა არ არის)
4. მოდით დავაყენოთ ხმის გადამოწმება, როგორც CI/CD მილსადენის ნაწილი
5. ჩვენ კრძალავს დაცულ ფილიალებს ვალდებულებების მიღებას; ყველა ცვლილება ხდება მხოლოდ MR-ის მეშვეობით
6. მოდით შევამოწმოთ რა მოხდა ბოლოს

1. შექმენით ჟეტონი API-ზე წვდომისთვის

გადადით მომხმარებლის პარამეტრებზე → წვდომის ჟეტონებზე და ჩაწერეთ ჟეტონი:

ანგარიში ტოკენის მისაღებად
API წვდომა საშუალებას გაძლევთ გააკეთოთ თითქმის ყველაფერი თქვენი საცავებით, ამიტომ გირჩევთ შექმნათ ცალკე Gitlab ანგარიში, მისცეთ მინიმალური უფლებები თქვენს საცავებზე (მაგ. Reporter) და მიიღოთ ტოკენი ამ ანგარიშისთვის.

2. დაამატეთ ჟეტონი Gitlab ცვლადებს

მაგალითად, წინა ეტაპზე მივიღეთ ჟეტონი QmN2Y0NOUFlfeXhvd21ZS01aQzgK

გახსენით პარამეტრები → CI/CD → ცვლადები → ცვლადის დამატება → GITLAB_TOKEN_FOR_CI

შედეგად ვიღებთ:

ეს შეიძლება გაკეთდეს როგორც ერთ საცავზე, ასევე საცავების ჯგუფზე.

3. ჩვენ ვაკრძალავთ Merge-ს, თუ კოლეგების თანხმობა არ მიიღება კოდის განხილვის შემდეგ.

ჩვენს შემთხვევაში, შერწყმის აკრძალვა იქნება ის, რომ ასამბლეის მილსადენი დააბრუნებს შეცდომას, თუ საკმარისი ხმები არ იქნება.

გადადით პარამეტრებში → ზოგადი → გაერთიანების მოთხოვნები → შერწყმის შემოწმებები და ჩართეთ პარამეტრი, რომელიც წარმატებით უნდა დასრულდეს ასამბლეის ხაზები.

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 ფაილის სინტაქსში, ის არ გაანადგურებს თქვენს წარმოების მილსადენს, არამედ უბრალოდ დაბლოკავს Merge-ს.

კონტეინერების მაგალითი ლიტრით, რომელიც შეგიძლიათ ააშენოთ თქვენს მილსადენში:

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-ს და ვაყენებთ "dislike".

მშენებლობის ჟურნალებში:

ახლა ჩადეთ „ლაიქი“ და კვლავ დაიწყეთ შემოწმება:

წყარო: www.habr.com