Pagsusuri ng code sa Gitlab CE: kung walang pag-apruba ng kahilingan sa Pagsamahin, ngunit gusto ko talaga

Ang isa sa mga pinaka-kinakailangang function, na wala sa libreng bersyon ng GitLab, ay ang kakayahang bumoto laban sa pagpapawalang-bisa ng repositoryo at kontrolin ang kahilingan sa Pagsama-sama (MR), gamit ang mandatoryong pagsusuri sa code.

Gawin natin mismo ang pinakamababang functionality - ipagbabawal namin ang Merge hanggang sa bigyan ng thumbs up ng ilang developer si MR.

Bakit kailangan pa ito?

Madaling kayang bumili ng lisensya ng GitLab ng aming organisasyon. Ngunit, dahil ang pag-unlad ay isinasagawa sa isang saradong loop nang walang pag-access sa Internet, at mayroong mahigpit na pagpaplano ng badyet, ang pagbili ng mga self-managed na lisensya na may kinakailangang pag-andar ay maaaring mag-drag sa loob ng maraming buwan, ngunit ang trabaho ay kailangang gawin ngayon.

Bilang resulta, kailangan mong:

• o ganap na ipagbawal ang Pagsamahin sa mga protektadong sangay para sa ilang developer, ngunit pagkatapos ay ang mga developer na may karapatang mag-Merge ay makakatanggap ng mga salungatan kapag pinagsasama ang mga MR ng ibang tao bilang bonus;
• o bigyan ng pagkakataon na gumawa ng hindi nakokontrol na mga pagsasanib sa iyong master branch nang walang pagsusuri sa code, kahit na si Junior, na natanggap kahapon lang.

Ang unang bagay na ginawa ko ay ang Google, na naniniwala na ang isang tao ay talagang nakagawa na ng katulad na bagay (nang hindi binabago ang code), ngunit ito ay lumabas na wala pang ganoong pagpapatupad sa bersyon ng komunidad.

Pangkalahatang pamamaraan ng trabaho

Bilang halimbawa, i-configure natin ang mga pag-apruba ng kahilingan sa Pagsamahin sa isang pansubok na repository myapp:

1. Gumawa tayo ng token para sa access sa GitLab API (sa pamamagitan nito makakatanggap tayo ng impormasyon tungkol sa bilang ng mga boto "para sa" at "laban")
2. Idagdag natin ang token sa mga variable ng GitLab
3. I-disable natin ang Merge kung sakaling magkaroon ng mga error sa pipeline (kung walang sapat na upvotes)
4. I-set up natin ang pag-verify ng boto bilang bahagi ng pipeline ng CI/CD
5. Ipinagbabawal namin ang paggawa ng mga commit sa mga protektadong sangay; lahat ng pagbabago ay ginagawa lamang sa pamamagitan ng MR
6. Suriin natin kung ano ang nangyari sa huli

1. Gumawa ng token para ma-access ang API

Pumunta sa Mga Setting ng User → Access Token at isulat ang token:

Account para makatanggap ng token
Nagbibigay-daan sa iyo ang pag-access sa API na gawin ang halos anumang bagay sa iyong mga repositoryo, kaya inirerekomenda ko ang paglikha ng isang hiwalay na Gitlab account, na nagbibigay ito ng kaunting karapatan sa iyong mga repositoryo (hal. Reporter) at pagkuha ng token para sa account na iyon.

2. Idagdag ang token sa mga variable ng Gitlab

Halimbawa, sa nakaraang hakbang nakatanggap kami ng token QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Buksan ang Mga Setting → CI/CD → Mga Variable → Magdagdag ng variable → GITLAB_TOKEN_FOR_CI

Bilang resulta, nakukuha namin ang:

Magagawa ito alinman sa isang repositoryo o sa isang pangkat ng mga repositoryo.

3. Naglalagay kami ng pagbabawal sa Merge kung ang pag-apruba ng mga kasamahan ay hindi natanggap pagkatapos ng pagsusuri sa code.

Sa aming kaso, ang pagbabawal sa Merge ay ang assembly pipeline ay magbabalik ng error kung walang sapat na boto.

Pumunta sa Mga Setting → Pangkalahatan → Pagsamahin ang Mga Kahilingan → Pagsamahin ang Mga Pagsusuri at paganahin ang opsyon Ang mga linya ng pagpupulong ay dapat na matagumpay na makumpleto.

4. Pagse-set up ng pipeline

Kung hindi ka pa nakakagawa ng pipeline ng CI/CD para sa iyong aplikasyon
Lumikha ng isang file sa ugat ng repositoryo .gitlab-ci.yml na may pinakasimpleng nilalaman:

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"

Paghiwalayin ang repository para sa configuration ng CI/CD
Inirerekomenda ko ang paggawa ng hiwalay na repository kung saan kailangan mong lumikha ng myapp.gitlab-ci.yml file para i-configure ang pipeline. Sa ganitong paraan mas makokontrol mo ang pag-access ng mga kalahok na maaaring magbago ng build pipeline at makatanggap ng access token.

Ang lokasyon ng bagong pipeline file ay kailangang tukuyin sa pamamagitan ng pagpunta sa myapp repository - Mga Setting - CI/CD - Assembly lines - Custom CI configuration path - tukuyin ang bagong file, hal. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Tip: Gumamit ng linter para gumawa ng mga pagbabago sa mga GitLab CI file
Kahit na nagtatrabaho ka nang mag-isa, ang pagtatrabaho sa pamamagitan ng MR ay magiging isang magandang tulong, na pinapatakbo ang lahat ng iyong mga pagbabago sa mga pipeline file sa pamamagitan ng isang linter. Kung magkamali ka sa syntax ng YAML file, hindi nito masisira ang iyong production pipeline, ngunit haharangan lang ang Merge.

Isang halimbawa ng mga lalagyan na may mga linter na maaari mong itayo sa iyong pipeline:

hub.docker.com/r/gableroux/gitlab-ci-lint
hub.docker.com/r/sebiwi/gitlab-ci-validate

At isang halimbawa ng yugto ng pag-verify:

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;

Ito ay nananatiling magdagdag ng ilang mga parameter sa iyong pipeline upang gawin itong gumana:

stages:
- test

variables:
NEED_VOTES: 1

include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

Tinutukoy ng NEED_VOTES variable kung gaano karaming "thumbs up" ang MR upang maging available ang Merge. Ang halaga na katumbas ng isa ay nangangahulugan na ikaw mismo ay maaaring aprubahan ang iyong MR sa pamamagitan ng "paggusto" nito.

kasama ang yugto ng pagsubok, na sumusuri sa bilang ng mga "gusto".

Ang pinakasimpleng pipeline gamit ang halimbawa ng 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

Mga nilalaman 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/.*$/'


Higit pang impormasyon tungkol sa kung ano ang nangyayari sa panahon ng pag-verify:

• may restriction na gagawin lang ang check kapag gumagawa ng MR sa master or release/* branches
• gamit ang GitLab API, nakukuha namin ang bilang ng "gusto" at "hindi gusto"
• kalkulahin ang pagkakaiba sa pagitan ng positibo at negatibong mga tugon
• kung ang pagkakaiba ay mas mababa kaysa sa halaga na itinakda namin sa NEED_VOTES, pagkatapos ay i-block namin ang kakayahang mag-merge

5. Ipagbawal ang mga commit sa mga protektadong sangay

Tinukoy namin ang mga sangay kung saan dapat kaming magsagawa ng mga pagsusuri sa code at ipahiwatig na maaari lamang silang magtrabaho sa pamamagitan ng MR.

Upang gawin ito, pumunta sa Mga Setting → Repository → Mga Protektadong Sangay:

6. Suriin

Itakda ang NEED_VOTES: 0

Gumagawa kami ng MR at naglalagay ng "dislike".

Sa mga build log:

Ngayon ilagay ang "like" at simulang suriin muli:

Pinagmulan: www.habr.com