Salah satu fungsi yang paling diperlukan, yang tiada dalam versi percuma GitLab, ialah keupayaan untuk mengundi menentang pembatalan repositori dan mengawal permintaan Gabung (MR), menggunakan semakan kod mandatori.
Mari lakukan sendiri kefungsian minimum - kami akan melarang Gabung sehingga beberapa pembangun memberikan MR pujian.
Mengapa ini perlu?
Organisasi kami mampu membeli lesen GitLab dengan mudah. Tetapi, kerana pembangunan dijalankan dalam gelung tertutup tanpa akses Internet, dan terdapat perancangan belanjawan yang ketat, pembelian lesen urus sendiri dengan fungsi yang diperlukan boleh berlarutan selama beberapa bulan, tetapi kerja perlu dilakukan sekarang.
Akibatnya anda perlu:
- atau melarang sepenuhnya Gabung dalam cawangan yang dilindungi untuk sesetengah pembangun, tetapi kemudian pembangun yang mempunyai hak untuk Gabung menerima konflik apabila menggabungkan MR orang lain sebagai bonus;
- atau beri peluang untuk membuat gabungan tidak terkawal dengan cawangan induk anda tanpa semakan kod, walaupun Junior, yang diupah baru semalam.
Perkara pertama yang saya lakukan ialah Google, percaya bahawa seseorang pasti telah melakukan sesuatu yang serupa (tanpa mengubah suai kod), tetapi ternyata belum ada pelaksanaan sedemikian dalam versi komuniti.
Skim kerja umum
Sebagai contoh, mari kita konfigurasikan kelulusan permintaan Gabungan pada repositori ujian :
- Mari buat token untuk akses kepada API GitLab (melaluinya kami akan menerima maklumat tentang bilangan undian "untuk" dan "menentang")
- Mari tambahkan token pada pembolehubah GitLab
- Mari lumpuhkan Gabung sekiranya berlaku ralat dalam perancangan (jika undian tidak mencukupi)
- Mari sediakan pengesahan undian sebagai sebahagian daripada saluran paip CI/CD
- Kami melarang membuat komitmen kepada cawangan yang dilindungi; semua perubahan dibuat hanya melalui MR
- Mari kita semak apa yang berlaku pada akhirnya
1. Buat token untuk mengakses API
Pergi ke Tetapan Pengguna → Token Akses dan tuliskan token:
Akaun untuk menerima token
Akses API membolehkan anda melakukan hampir apa sahaja dengan repositori anda, jadi saya syorkan anda membuat akaun Gitlab yang berasingan, memberikan hak minimum kepada repositori anda (cth Reporter) dan mendapatkan token untuk akaun tersebut.
2. Tambahkan token pada pembolehubah Gitlab
Sebagai contoh, dalam langkah sebelumnya kami menerima token QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Buka Tetapan → CI/CD → Pembolehubah → Tambah pembolehubah → GITLAB_TOKEN_FOR_CI
Hasilnya kami mendapat:
Ini boleh dilakukan sama ada pada satu repositori atau pada sekumpulan repositori.
3. Kami meletakkan larangan pada Merge jika kelulusan rakan sekerja tidak diterima selepas semakan kod.
Dalam kes kami, larangan Gabungan ialah saluran paip pemasangan akan mengembalikan ralat jika undi tidak mencukupi.
Pergi ke Tetapan → Umum → Gabung Permintaan → Gabung Cek dan dayakan pilihan Barisan pemasangan mesti berjaya diselesaikan.
4. Menyediakan saluran paip
Jika anda masih belum membuat saluran paip CI/CD untuk permohonan anda
Buat fail dalam akar repositori .gitlab-ci.yml dengan kandungan yang paling mudah:
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"
Repositori berasingan untuk konfigurasi CI/CD
Saya akan mengesyorkan membuat repositori berasingan di mana anda perlu mencipta fail myapp.gitlab-ci.yml untuk mengkonfigurasi saluran paip. Dengan cara ini anda boleh mengawal akses peserta dengan lebih baik yang boleh menukar saluran paip binaan dan menerima token akses.
Lokasi fail saluran paip baharu perlu ditentukan dengan pergi ke repositori myapp - Tetapan - CI/CD - Barisan pemasangan - Laluan konfigurasi CI tersuai - nyatakan fail baharu, mis. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Petua: Gunakan linter untuk membuat perubahan pada fail GitLab CI
Walaupun anda bekerja bersendirian, bekerja melalui MR akan menjadi bantuan yang baik, menjalankan semua perubahan anda pada fail saluran paip melalui linter. Jika anda membuat kesilapan dalam sintaks fail YAML, ia tidak akan memecahkan saluran pengeluaran anda, tetapi hanya akan menyekat Gabungan.
Contoh bekas dengan linter yang boleh anda bina ke dalam saluran paip anda:
Dan contoh peringkat pengesahan:
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;
Ia kekal untuk menambah beberapa parameter pada saluran paip anda untuk menjadikannya berfungsi:
stages:
- test
variables:
NEED_VOTES: 1
include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"
Pembolehubah NEED_VOTES menentukan bilangan "thumbs up" yang perlu ada MR agar Gabungan tersedia. Nilai yang sama dengan satu bermakna anda sendiri boleh meluluskan MR anda dengan "menyukainya".
termasuk termasuk peringkat ujian, yang menyemak bilangan "suka".
Saluran paip paling mudah menggunakan contoh 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
Kandungan 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/.*$/'
Maklumat lanjut tentang perkara yang berlaku semasa pengesahan:
- terdapat sekatan bahawa semakan hanya akan dilakukan apabila mencipta MR dalam cawangan induk atau keluaran/*
- menggunakan API GitLab, kami mendapat bilangan "suka" dan "tidak suka"
- kira perbezaan antara tindak balas positif dan negatif
- jika perbezaannya kurang daripada nilai yang kami tetapkan dalam NEED_VOTES, maka kami menyekat keupayaan untuk bergabung
5. Melarang komitmen terhadap cawangan yang dilindungi
Kami mentakrifkan cawangan yang mana kami mesti menjalankan semakan kod dan menunjukkan bahawa mereka hanya boleh diusahakan melalui MR.
Untuk melakukan ini, pergi ke Tetapan → Repositori → Cawangan Dilindungi:
6. Semak
Tetapkan NEED_VOTES: 0
Kami membuat MR dan meletakkan "tidak suka".
Dalam log binaan:
Sekarang letakkan "suka" dan mula semak semula:
Sumber: www.habr.com