ການທົບທວນລະຫັດໃນ Gitlab CE: ຖ້າບໍ່ມີການອະນຸມັດການຮ້ອງຂໍການລວມເຂົ້າກັນ, ແຕ່ຂ້ອຍກໍ່ຕ້ອງການ

ຫນຶ່ງໃນຫນ້າທີ່ມີຄວາມຈໍາເປັນທີ່ສຸດ, ທີ່ບໍ່ມີຢູ່ໃນສະບັບຟຣີຂອງ GitLab, ແມ່ນຄວາມສາມາດໃນການລົງຄະແນນສຽງຕໍ່ກັບການ nullification repository ແລະການຄວບຄຸມການຮ້ອງຂໍການລວມເຂົ້າກັນ (MR), ການນໍາໃຊ້ການທົບທວນລະຫັດບັງຄັບ.

ໃຫ້ເຮົາເຮັດຫນ້າທີ່ຕໍາ່ສຸດທີ່ຕົວເຮົາເອງ - ພວກເຮົາຈະຫ້າມ Merge ຈົນກ່ວານັກພັດທະນາຫຼາຍຄົນຍົກໂປ້ MR.

ເປັນຫຍັງອັນນີ້ຈຶ່ງຈໍາເປັນ?

ອົງການຈັດຕັ້ງຂອງພວກເຮົາສາມາດຊື້ໃບອະນຸຍາດ GitLab ໄດ້ຢ່າງງ່າຍດາຍ. ແຕ່, ເນື່ອງຈາກວ່າການພັດທະນາແມ່ນດໍາເນີນຢູ່ໃນວົງປິດໂດຍບໍ່ມີການເຂົ້າເຖິງອິນເຕີເນັດ, ແລະມີການວາງແຜນງົບປະມານຢ່າງເຂັ້ມງວດ, ການຊື້ໃບອະນຸຍາດຄຸ້ມຄອງຕົນເອງທີ່ມີຫນ້າທີ່ທີ່ຈໍາເປັນສາມາດລາກໄປເປັນເວລາຫຼາຍເດືອນ, ແຕ່ການເຮັດວຽກຕ້ອງໄດ້ເຮັດໃນປັດຈຸບັນ.

ດັ່ງນັ້ນ, ທ່ານຈະຕ້ອງ:

• ຫຼືຫ້າມຢ່າງສົມບູນ Merge ໃນສາຂາທີ່ໄດ້ຮັບການປົກປ້ອງສໍາລັບນັກພັດທະນາບາງຄົນ, ແຕ່ຫຼັງຈາກນັ້ນຜູ້ພັດທະນາທີ່ມີສິດທີ່ຈະ Merge ໄດ້ຮັບການຂັດແຍ້ງໃນເວລາທີ່ລວມ MRs ຂອງຜູ້ອື່ນເປັນໂບນັດ;
• ຫຼືໃຫ້ໂອກາດທີ່ຈະເຮັດໃຫ້ການຜະສົມຜະສານທີ່ບໍ່ສາມາດຄວບຄຸມໄດ້ກັບສາຂາຕົ້ນສະບັບຂອງທ່ານໂດຍບໍ່ມີການທົບທວນລະຫັດ, ເຖິງແມ່ນວ່າມັນເປັນ Junior, ຜູ້ທີ່ຖືກຈ້າງໃນມື້ວານນີ້.

ສິ່ງທໍາອິດທີ່ຂ້ອຍເຮັດແມ່ນ Google, ເຊື່ອວ່າບາງຄົນໄດ້ເຮັດບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນແລ້ວ (ໂດຍບໍ່ມີການດັດແປງລະຫັດ), ແຕ່ມັນປາກົດວ່າບໍ່ມີການປະຕິບັດດັ່ງກ່າວໃນສະບັບຊຸມຊົນເທື່ອ.

ໂຄງ​ການ​ທົ່ວ​ໄປ​ຂອງ​ການ​ເຮັດ​ວຽກ​

ຕົວຢ່າງ, ໃຫ້ເຮົາຕັ້ງຄ່າການອະນຸມັດການຮ້ອງຂໍການຮວມຢູ່ໃນບ່ອນເກັບຂໍ້ມູນການທົດສອບ myapp:

1. ໃຫ້ສ້າງ token ສໍາລັບການເຂົ້າເຖິງ GitLab API (ຜ່ານມັນພວກເຮົາຈະໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບຈໍານວນຂອງການລົງຄະແນນສຽງ "ສໍາລັບ" ແລະ "ຕໍ່")
2. ໃຫ້ເພີ່ມ token ໃຫ້ກັບຕົວແປ GitLab
3. ໃຫ້ປິດການລວມເຂົ້າກັນໃນກໍລະນີເກີດຄວາມຜິດພາດໃນທໍ່ (ຖ້າບໍ່ມີຄະແນນ upvotes ພຽງພໍ)
4. ມາຕັ້ງການກວດສອບຄະແນນສຽງເປັນສ່ວນໜຶ່ງຂອງທໍ່ CI/CD
5. ພວກເຮົາຫ້າມການເຮັດສັນຍາກັບສາຂາທີ່ຖືກປົກປ້ອງ; ການປ່ຽນແປງທັງຫມົດແມ່ນເຮັດຜ່ານ MR ເທົ່ານັ້ນ
6. ໃຫ້ກວດເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນໃນທີ່ສຸດ

1. ສ້າງ token ເພື່ອເຂົ້າເຖິງ API

ໄປທີ່ການຕັ້ງຄ່າຜູ້ໃຊ້ → Access Token ແລະຂຽນໂທເຄັນລົງ:

ບັນຊີທີ່ຈະໄດ້ຮັບໂທເຄັນ
ການເຂົ້າເຖິງ API ອະນຸຍາດໃຫ້ທ່ານເຮັດເກືອບທຸກຢ່າງກັບ repositories ຂອງທ່ານ, ສະນັ້ນຂ້າພະເຈົ້າແນະນໍາໃຫ້ສ້າງບັນຊີ Gitlab ແຍກຕ່າງຫາກ, ໃຫ້ມັນສິດທິຫນ້ອຍທີ່ສຸດກັບ repositories ຂອງທ່ານ (ເຊັ່ນ: Reporter) ແລະໄດ້ຮັບ token ສໍາລັບບັນຊີນັ້ນ.

2. ເພີ່ມ token ກັບຕົວແປ Gitlab

ຕົວຢ່າງ, ໃນຂັ້ນຕອນທີ່ຜ່ານມາພວກເຮົາໄດ້ຮັບ token QmN2Y0NOUFlfeXhvd21ZS01aQzgK

ເປີດການຕັ້ງຄ່າ → CI/CD → ຕົວແປ → ເພີ່ມຕົວແປ → GITLAB_TOKEN_FOR_CI

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບ:

ນີ້ສາມາດເຮັດໄດ້ທັງໃນຫນຶ່ງ repository ຫຼືໃນກຸ່ມຂອງ repositories.

3. ພວກເຮົາວາງຂໍ້ຫ້າມກ່ຽວກັບການ Merge ຖ້າການອະນຸມັດຂອງເພື່ອນຮ່ວມງານບໍ່ໄດ້ຮັບຫຼັງຈາກການທົບທວນຄືນລະຫັດ.

ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ພວກ​ເຮົາ​, ຂໍ້​ຫ້າມ​ກ່ຽວ​ກັບ​ການ Merge ແມ່ນ​ວ່າ​ທໍ່​ການ​ປະ​ກອບ​ຈະ​ກັບ​ຄືນ​ມາ​ຄວາມ​ຜິດ​ພາດ​ຖ້າ​ຫາກ​ວ່າ​ບໍ່​ມີ​ຄະ​ແນນ​ສຽງ​ພຽງ​ພໍ​.

ໄປ​ທີ່ Settings → General → Merge Requests → Merge Checks ແລະ​ເປີດ​ໃຊ້​ງານ​ທາງ​ເລືອກ​ຂອງ​ສາຍ Assembly ຕ້ອງ​ສໍາ​ເລັດ​ຢ່າງ​ສໍາ​ເລັດ​ຜົນ​.

4. ການຕັ້ງທໍ່

ຖ້າທ່ານຍັງບໍ່ໄດ້ສ້າງທໍ່ CI/CD ສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງທ່ານ
ສ້າງໄຟລ໌ຢູ່ໃນຮາກຂອງ repository .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 ເພື່ອຕັ້ງຄ່າທໍ່. ວິທີນີ້ທ່ານສາມາດຄວບຄຸມການເຂົ້າເຖິງຂອງຜູ້ເຂົ້າຮ່ວມໄດ້ດີກວ່າທີ່ສາມາດປ່ຽນທໍ່ກໍ່ສ້າງແລະໄດ້ຮັບ token ການເຂົ້າເຖິງ.

ສະຖານທີ່ຂອງໄຟລ໌ທໍ່ໃຫມ່ຈະຕ້ອງຖືກກໍານົດໂດຍການໄປທີ່ myapp repository - ການຕັ້ງຄ່າ - CI/CD - ເສັ້ນສະພາແຫ່ງ - ເສັ້ນທາງການຕັ້ງຄ່າ CI Custom - ລະບຸໄຟລ໌ໃຫມ່, e.g. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

ເຄັດລັບ: ໃຊ້ linter ເພື່ອປ່ຽນແປງໄຟລ໌ GitLab CI
ເຖິງແມ່ນວ່າທ່ານເຮັດວຽກຄົນດຽວ, ການເຮັດວຽກຜ່ານ MR ຈະເປັນການຊ່ວຍເຫຼືອທີ່ດີ, ດໍາເນີນການການປ່ຽນແປງທັງຫມົດຂອງທ່ານກັບໄຟລ໌ທໍ່ຜ່ານ linter. ຖ້າທ່ານເຮັດຜິດພາດໃນ syntax ຂອງໄຟລ໌ YAML, ມັນຈະບໍ່ທໍາລາຍທໍ່ການຜະລິດຂອງທ່ານ, ແຕ່ພຽງແຕ່ຈະຂັດຂວາງການລວມເຂົ້າກັນ.

ຕົວຢ່າງຂອງຖັງທີ່ມີ linters ທີ່ທ່ານສາມາດສ້າງເຂົ້າໄປໃນທໍ່ຂອງທ່ານ:

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 ຕ້ອງມີເພື່ອໃຫ້ Merge ສາມາດໃຊ້ໄດ້. ມູນຄ່າເທົ່າກັບຫນຶ່ງຫມາຍຄວາມວ່າຕົວທ່ານເອງສາມາດອະນຸມັດ 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 ເທົ່ານັ້ນ.

ເພື່ອເຮັດສິ່ງນີ້, ໄປທີ່ Settings → Repository → Protected Branches:

6. ກວດກາ

ກຳນົດ NEED_VOTES: 0

ພວກເຮົາສ້າງ MR ແລະໃສ່ "ບໍ່ມັກ".

ໃນ​ບັນ​ທຶກ​ການ​ກໍ່​ສ້າງ​:

ຕອນນີ້ໃສ່ "ມັກ" ແລະເລີ່ມກວດເບິ່ງອີກເທື່ອຫນຶ່ງ:

ແຫຼ່ງຂໍ້ມູນ: www.habr.com