GitLab-ийн үнэгүй хувилбарт байдаггүй хамгийн чухал функцүүдийн нэг нь репозиторыг хүчингүй болгохын эсрэг санал өгөх, кодыг заавал шалгах замаар нэгтгэх хүсэлтийг (MR) хянах явдал юм.
Хамгийн бага функцийг өөрсдөө хийцгээе - хэд хэдэн хөгжүүлэгчид MR-д эрхий хуруугаа өргөх хүртэл бид нэгтгэхийг хориглоно.
Энэ нь яагаад зайлшгүй шаардлагатай вэ?
Манай байгууллага GitLab лицензийг хялбархан худалдаж авах боломжтой. Гэхдээ бүтээн байгуулалт нь интернет холболтгүй хаалттай циклээр явагддаг бөгөөд төсвийн хатуу төлөвлөлт байдаг тул шаардлагатай функц бүхий өөрөө удирддаг лицензийг худалдаж авах нь олон сарын турш үргэлжилж болох ч одоо ажил хийх шаардлагатай байна.
Үүний үр дүнд та:
- эсвэл зарим хөгжүүлэгчдийн хувьд хамгаалагдсан салбаруудад Merge-г бүрэн хориглох боловч дараа нь нэгтгэх эрхтэй хөгжүүлэгчид бусад хүмүүсийн MR-г урамшуулал болгон нэгтгэх үед зөрчилддөг;
- эсвэл өчигдөр ажилд орсон Жуниор байсан ч гэсэн кодын хяналтгүйгээр мастер салбартайгаа хяналтгүй нэгдэх боломжийг олго.
Миний хийсэн хамгийн эхний зүйл бол Google-д хэн нэгэн үүнтэй төстэй зүйлийг (кодыг өөрчлөхгүйгээр) аль хэдийн хийсэн гэдэгт итгэж байсан боловч олон нийтийн хувилбарт ийм хэрэгжилт хараахан гараагүй байна.
Ажлын ерөнхий схем
Жишээ болгон, туршилтын сан дээр Merge хүсэлтийн зөвшөөрлийг тохируулъя
- GitLab API-д нэвтрэх токен үүсгэцгээе (түүгээр дамжуулан бид "дэвхтэй" болон "эсрэг" гэсэн саналын тооны талаарх мэдээллийг хүлээн авах болно)
- GitLab хувьсагчдад токен нэмье
- Дамжуулах хоолойд алдаа гарсан тохиолдолд нэгтгэхийг идэвхгүй болгоё (хэрэв хангалттай сайн санал байхгүй бол)
- CI/CD шугамын нэг хэсэг болгон саналын баталгаажуулалтыг тохируулцгаая
- Бид хамгаалагдсан салбаруудад үүрэг өгөхийг хориглодог, бүх өөрчлөлтийг зөвхөн MR-ээр хийдэг
- Эцэст нь юу болсныг шалгацгаая
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 - Ассемблей шугамууд - Custom CI тохиргооны зам - шинэ файлыг зааж өгнө, ж.нь. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Зөвлөмж: GitLab CI файлд өөрчлөлт оруулахын тулд линтер ашиглана уу
Хэдийгээр та ганцаараа ажилладаг байсан ч MR-ээр ажиллах нь дамжуулах шугамын файлд хийсэн бүх өөрчлөлтийг линтерээр дамжуулан явуулахад маш сайн туслах болно. Хэрэв та YAML файлын синтакс дээр алдаа гаргавал энэ нь таны үйлдвэрлэлийн шугамыг таслахгүй, харин зүгээр л нэгтгэхийг хаах болно.
Шугам хоолойдоо барьж болох савны жишээ:
Баталгаажуулах шатны жишээ:
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 хувьсагч нь 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-ээр дамжуулан ажиллах боломжтойг зааж өгдөг.
Үүнийг хийхийн тулд Тохиргоо → Хадгалах газар → Хамгаалагдсан салбар руу очно уу:
6. Шалгах
NEED_VOTES-г тохируулах: 0
Бид MR хийж, "дургүй" гэсэн тэмдэг тавьдаг.
Барилгын бүртгэлд:
Одоо "дуртай"-г тавиад дахин шалгаж эхлээрэй:
Эх сурвалж: www.habr.com