การตรวจสอบโค้ดใน Gitlab CE: หากไม่มีการอนุมัติคำขอ Merge แต่ฉันต้องการจริงๆ

หนึ่งในฟังก์ชันที่จำเป็นที่สุดซึ่งไม่ได้อยู่ใน GitLab เวอร์ชันฟรี คือความสามารถในการลงคะแนนต่อต้านการลบล้างพื้นที่เก็บข้อมูลและควบคุมคำขอผสาน (MR) โดยใช้การตรวจสอบโค้ดที่บังคับ

เรามาทำหน้าที่ขั้นต่ำด้วยตัวเองกันเถอะ - เราจะห้ามไม่ให้ Merge จนกว่านักพัฒนาหลายคนจะยกนิ้วให้ MR

เหตุใดสิ่งนี้จึงจำเป็น?

องค์กรของเราสามารถซื้อใบอนุญาต GitLab ได้อย่างง่ายดาย แต่เนื่องจากการพัฒนาดำเนินไปในวงปิดโดยไม่มีการเข้าถึงอินเทอร์เน็ต และมีการวางแผนงบประมาณที่เข้มงวด การซื้อใบอนุญาตแบบจัดการตนเองพร้อมฟังก์ชันที่จำเป็นอาจใช้เวลานานหลายเดือน แต่งานจำเป็นต้องทำให้เสร็จในตอนนี้

ดังนั้นคุณจะต้อง:

• หรือห้ามโดยสิ้นเชิงในการรวมสาขาที่ได้รับการคุ้มครองสำหรับนักพัฒนาบางราย แต่จากนั้นนักพัฒนาที่มีสิทธิ์ในการรวมจะได้รับข้อขัดแย้งเมื่อรวม MR ของผู้อื่นเป็นโบนัส
• หรือให้โอกาสในการรวมเข้ากับสาขาหลักของคุณโดยไม่มีการควบคุมโดยไม่ต้องตรวจสอบโค้ด แม้ว่าจะเป็นรุ่นจูเนียร์ที่เพิ่งได้รับการว่าจ้างเมื่อวานนี้ก็ตาม

สิ่งแรกที่ฉันทำคือ Google โดยเชื่อว่ามีคนทำสิ่งที่คล้ายกันอย่างแน่นอน (โดยไม่ต้องแก้ไขโค้ด) แต่กลับกลายเป็นว่ายังไม่มีการใช้งานดังกล่าวในเวอร์ชันชุมชน

รูปแบบการทำงานทั่วไป

ตามตัวอย่าง เราจะกำหนดค่าการอนุมัติคำขอผสานบนพื้นที่เก็บข้อมูลทดสอบ แอปของฉัน:

1. มาสร้างโทเค็นเพื่อเข้าถึง GitLab API กันเถอะ (โดยเราจะได้รับข้อมูลเกี่ยวกับจำนวนโหวต "สำหรับ" และ "ต่อต้าน")
2. มาเพิ่มโทเค็นให้กับตัวแปร GitLab
3. มาปิดการใช้งาน Merge ในกรณีที่เกิดข้อผิดพลาดในไปป์ไลน์ (หากมีการโหวตไม่เพียงพอ)
4. มาตั้งค่าการตรวจสอบการลงคะแนนเสียงโดยเป็นส่วนหนึ่งของไปป์ไลน์ CI/CD
5. เราห้ามกระทำการผูกพันกับสาขาที่ได้รับการคุ้มครอง การเปลี่ยนแปลงทั้งหมดจะทำผ่าน MR เท่านั้น
6. เรามาตรวจสอบสิ่งที่เกิดขึ้นในที่สุด

1. สร้างโทเค็นเพื่อเข้าถึง API

ไปที่การตั้งค่าผู้ใช้ → โทเค็นการเข้าถึง และจดโทเค็น:

บัญชีเพื่อรับโทเค็น
การเข้าถึง API ช่วยให้คุณสามารถทำอะไรได้เกือบทุกอย่างกับพื้นที่เก็บข้อมูลของคุณ ดังนั้น ฉันขอแนะนำให้สร้างบัญชี Gitlab แยกต่างหาก โดยให้สิทธิ์ขั้นต่ำแก่พื้นที่เก็บข้อมูลของคุณ (เช่น โปรแกรมรายงาน) และรับโทเค็นสำหรับบัญชีนั้น

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

เคล็ดลับ: ใช้ linter เพื่อทำการเปลี่ยนแปลงไฟล์ GitLab CI
แม้ว่าคุณจะทำงานคนเดียว การทำงานผ่าน MR จะเป็นประโยชน์อย่างยิ่ง โดยเรียกใช้การเปลี่ยนแปลงทั้งหมดของคุณกับไฟล์ไปป์ไลน์ผ่าน linter หากคุณทำผิดพลาดในไวยากรณ์ของไฟล์ YAML มันจะไม่ทำให้ไปป์ไลน์การผลิตของคุณเสียหาย แต่จะบล็อก Merge เพียงอย่างเดียว

ตัวอย่างของคอนเทนเนอร์ที่มี liners ที่คุณสร้างลงในไปป์ไลน์ได้:

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 พร้อมใช้งาน ค่าเท่ากับ XNUMX หมายความว่าคุณเองสามารถอนุมัติ 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 ในสาขาหลักหรือ release/* เท่านั้น
• เมื่อใช้ GitLab API เราจะได้จำนวน "ไลค์" และ "ไม่ชอบ"
• คำนวณความแตกต่างระหว่างการตอบสนองเชิงบวกและเชิงลบ
• หากความแตกต่างน้อยกว่าค่าที่เรากำหนดไว้ใน NEED_VOTES เราจะบล็อกความสามารถในการรวม

5. ห้ามกระทำต่อสาขาที่ได้รับการคุ้มครอง

เรากำหนดสาขาที่เราต้องทำการตรวจสอบโค้ดและระบุว่าสามารถทำงานได้ผ่าน MR เท่านั้น

หากต้องการทำสิ่งนี้ ให้ไปที่การตั้งค่า → พื้นที่เก็บข้อมูล → สาขาที่ได้รับการคุ้มครอง:

6. ตรวจสอบ

ตั้งค่า NEED_VOTES: 0

เราสร้าง MR และใส่คำว่า "ไม่ชอบ"

ในบันทึกการสร้าง:

ตอนนี้ใส่ "ถูกใจ" และเริ่มตรวจสอบอีกครั้ง:

ที่มา: will.com