Tinjauan kode di Gitlab CE: jika tidak ada persetujuan permintaan Gabung, tapi saya sangat ingin

Tinjauan kode di Gitlab CE: jika tidak ada persetujuan permintaan Gabung, tapi saya sangat ingin

Salah satu fungsi yang paling penting, yang tidak ada dalam versi gratis GitLab, adalah kemampuan untuk memberikan suara menentang pembatalan repositori dan mengontrol permintaan Penggabungan (MR), menggunakan tinjauan kode wajib.

Mari kita lakukan sendiri fungsi minimumnya - kami akan melarang Penggabungan hingga beberapa pengembang mengacungkan jempol pada MR.

Mengapa ini perlu?

Organisasi kami dapat dengan mudah membeli lisensi GitLab. Namun, karena pengembangan dilakukan secara tertutup tanpa akses Internet, dan terdapat perencanaan anggaran yang ketat, pembelian lisensi yang dikelola sendiri dengan fungsionalitas yang diperlukan dapat memakan waktu berbulan-bulan, namun pekerjaan harus dilakukan sekarang.

Akibatnya Anda harus:

  • atau sepenuhnya melarang Penggabungan di cabang yang dilindungi untuk beberapa pengembang, tetapi kemudian pengembang yang memiliki hak Penggabungan menerima konflik ketika menggabungkan MR orang lain sebagai bonus;
  • atau berikan kesempatan untuk melakukan penggabungan yang tidak terkendali dengan cabang master Anda tanpa tinjauan kode, meskipun Junior, yang baru saja dipekerjakan kemarin.

Hal pertama yang saya lakukan adalah Google, percaya bahwa seseorang pasti telah melakukan hal serupa (tanpa mengubah kode), tetapi ternyata belum ada implementasi seperti itu di versi komunitas.

Skema kerja umum

Sebagai contoh, mari konfigurasikan persetujuan permintaan Penggabungan pada repositori pengujian aplikasi saya:

  1. Mari kita buat token untuk akses ke GitLab API (melalui itu kita akan menerima informasi tentang jumlah suara "untuk" dan "menentang")
  2. Mari tambahkan token ke variabel GitLab
  3. Mari kita nonaktifkan Penggabungan jika terjadi kesalahan pada pipeline (jika suara positif tidak mencukupi)
  4. Mari kita siapkan verifikasi suara sebagai bagian dari pipeline CI/CD
  5. Kami melarang membuat komitmen pada cabang yang dilindungi; semua perubahan hanya dilakukan melalui MR
  6. Mari kita periksa apa yang terjadi pada akhirnya

1. Buat token untuk mengakses API

Buka Pengaturan Pengguna → Akses Token dan tulis tokennya:

Tinjauan kode di Gitlab CE: jika tidak ada persetujuan permintaan Gabung, tapi saya sangat ingin

Akun untuk menerima token
Akses API memungkinkan Anda melakukan hampir semua hal dengan repositori Anda, jadi saya sarankan untuk membuat akun Gitlab terpisah, memberinya hak minimal atas repositori Anda (misalnya Reporter) dan mendapatkan token untuk akun tersebut.

2. Tambahkan token ke variabel Gitlab

Misalnya pada langkah sebelumnya kita menerima token QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Buka Pengaturan → CI/CD → Variabel → Tambahkan variabel → GITLAB_TOKEN_FOR_CI

Tinjauan kode di Gitlab CE: jika tidak ada persetujuan permintaan Gabung, tapi saya sangat ingin

Hasilnya kita mendapatkan:

Tinjauan kode di Gitlab CE: jika tidak ada persetujuan permintaan Gabung, tapi saya sangat ingin

Hal ini dapat dilakukan pada satu repositori atau pada sekelompok repositori.

3. Kami melarang Penggabungan jika persetujuan rekan kerja tidak diterima setelah peninjauan kode.

Dalam kasus kami, larangan Penggabungan adalah bahwa pipa perakitan akan mengembalikan kesalahan jika tidak ada cukup suara.

Buka Pengaturan → Umum → Permintaan Penggabungan → Gabungkan Pemeriksaan dan aktifkan opsi Jalur perakitan harus berhasil diselesaikan.

Tinjauan kode di Gitlab CE: jika tidak ada persetujuan permintaan Gabung, tapi saya sangat ingin

4. Menyiapkan saluran pipa

Jika Anda belum membuat pipeline CI/CD untuk aplikasi Anda
Buat file di root repositori .gitlab-ci.yml dengan konten paling sederhana:

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 terpisah untuk konfigurasi CI/CD
Saya akan merekomendasikan membuat repositori terpisah di mana Anda perlu membuat file myapp.gitlab-ci.yml untuk mengonfigurasi pipeline. Dengan cara ini Anda dapat mengontrol akses peserta dengan lebih baik yang dapat mengubah alur build dan menerima token akses.

Lokasi file pipeline baru perlu ditentukan dengan masuk ke repositori myapp - Pengaturan - CI/CD - Jalur perakitan - Jalur konfigurasi CI khusus - tentukan file baru, mis. aplikasi saya.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Tip: Gunakan linter untuk membuat perubahan pada file GitLab CI
Bahkan jika Anda bekerja sendiri, bekerja melalui MR akan sangat membantu, menjalankan semua perubahan Anda pada file pipeline melalui linter. Jika Anda membuat kesalahan dalam sintaksis file YAML, hal ini tidak akan merusak jalur produksi Anda, namun hanya akan memblokir Penggabungan.

Contoh container dengan linter yang dapat Anda buat ke dalam pipeline Anda:

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

Dan contoh tahap verifikasinya :

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;

Tetap menambahkan beberapa parameter ke saluran Anda agar berfungsi:

stages:
- test

variables:
NEED_VOTES: 1

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

Variabel NEED_VOTES menentukan berapa banyak “jempol” yang harus dimiliki MR agar Penggabungan tersedia. Nilai yang sama dengan satu berarti Anda sendiri yang dapat menyetujui MR Anda dengan “menyukainya”.

include mencakup tahap pengujian, yang memeriksa jumlah “suka”.

Pipeline paling sederhana 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

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

Informasi lebih lanjut tentang apa yang terjadi selama verifikasi:

  • ada batasan bahwa pemeriksaan hanya akan dilakukan saat membuat MR di cabang master atau rilis/*
  • menggunakan API GitLab, kami mendapatkan jumlah "suka" dan "tidak suka"
  • menghitung perbedaan antara tanggapan positif dan negatif
  • jika selisihnya kurang dari nilai yang kita tetapkan di NEED_VOTES, maka kita memblokir kemampuan untuk menggabungkan

5. Melarang melakukan komitmen pada cabang yang dilindungi

Kami mendefinisikan cabang-cabang di mana kami harus melakukan tinjauan kode dan menunjukkan bahwa cabang-cabang tersebut hanya dapat dikerjakan melalui MR.

Untuk melakukan ini, buka Pengaturan → Repositori → Cabang yang Dilindungi:

Tinjauan kode di Gitlab CE: jika tidak ada persetujuan permintaan Gabung, tapi saya sangat ingin

6. Periksa

Setel NEED_VOTES: 0

Kami membuat MR dan memberi tanda "tidak suka".

Tinjauan kode di Gitlab CE: jika tidak ada persetujuan permintaan Gabung, tapi saya sangat ingin

Di log build:

Tinjauan kode di Gitlab CE: jika tidak ada persetujuan permintaan Gabung, tapi saya sangat ingin

Sekarang masukkan "suka" dan mulai periksa lagi:

Tinjauan kode di Gitlab CE: jika tidak ada persetujuan permintaan Gabung, tapi saya sangat ingin

Sumber: www.habr.com

Tambah komentar