🥇Panduan CI/CD di GitLab untuk (hampir) pemula mutlak

Atau cara mendapatkan lencana cantik untuk proyek Anda dalam satu malam pengodean mudah

Mungkin, setiap pengembang yang memiliki setidaknya satu proyek hewan peliharaan di beberapa titik merasa gatal tentang lencana indah dengan status, cakupan kode, versi paket di nuget ... Dan rasa gatal ini membuat saya menulis artikel ini. Dalam persiapan untuk menulisnya, saya mendapatkan keindahan ini di salah satu proyek saya:

Artikel ini akan memandu Anda melalui penyiapan dasar integrasi dan pengiriman berkelanjutan untuk proyek perpustakaan kelas .Net Core di GitLab, menerbitkan dokumentasi ke Halaman GitLab, dan mendorong paket yang dibuat ke umpan pribadi di Azure DevOps.

VS Code digunakan sebagai lingkungan pengembangan dengan ekstensi Alur Kerja GitLab (untuk memvalidasi file pengaturan langsung dari lingkungan pengembangan).

Pengantar singkat

CD - apakah saat Anda baru saja mendorong, dan semuanya sudah jatuh pada klien?

Apa itu CI / CD dan mengapa Anda membutuhkannya - Anda dapat dengan mudah mencarinya di Google. Temukan dokumentasi lengkap tentang cara mengonfigurasi pipeline di GitLab juga mudah. Di sini saya akan menjelaskan secara singkat dan, jika mungkin, tanpa kekurangan menjelaskan proses sistem dari pandangan mata burung:

pengembang mengirimkan komit ke repositori, membuat permintaan penggabungan melalui situs, atau dengan cara lain, secara eksplisit atau implisit memulai saluran pipa,
semua tugas dipilih dari konfigurasi, kondisi yang memungkinkannya diluncurkan dalam konteks tertentu,
tugas disusun menurut tahapannya,
tahapan dieksekusi secara bergiliran - mis. paralel semua tugas tahap ini selesai,
jika tahapan gagal (yaitu, setidaknya salah satu tugas tahapan gagal), saluran pipa berhenti (hampir selalu),
jika semua tahapan berhasil diselesaikan, pipeline dianggap berhasil.

Jadi, kami memiliki:

pipeline - serangkaian tugas yang diatur ke dalam tahapan di mana Anda dapat membangun, menguji, mengemas kode, menerapkan build yang telah selesai ke layanan cloud, dll.,
panggung (tahap) — unit organisasi pipa, berisi 1+ tugas,
tugas (pekerjaan) adalah unit kerja dalam pipa. Ini terdiri dari skrip (wajib), kondisi peluncuran, pengaturan untuk penerbitan/caching artefak, dan banyak lagi.

Oleh karena itu, tugas saat menyiapkan CI / CD adalah membuat serangkaian tugas yang mengimplementasikan semua tindakan yang diperlukan untuk membuat, menguji, dan menerbitkan kode dan artefak.

Sebelum memulai: mengapa?

Mengapa Gitlab?

Karena ketika perlu membuat repositori pribadi untuk proyek hewan peliharaan, mereka dibayar di GitHub, dan saya serakah. Repositori telah menjadi gratis, tetapi sejauh ini tidak cukup alasan bagi saya untuk pindah ke GitHub.

Mengapa tidak Azure DevOps Pipelines?

Karena di sana pengaturannya dasar - pengetahuan tentang baris perintah bahkan tidak diperlukan. Integrasi dengan penyedia git eksternal - dalam beberapa klik, impor kunci SSH untuk mengirim komit ke repositori - juga, pipa mudah dikonfigurasi bahkan bukan dari templat.

Posisi awal: apa yang Anda miliki dan apa yang Anda inginkan

Kami punya:

repositori di GitLab.

Kami ingin:

perakitan dan pengujian otomatis untuk setiap permintaan penggabungan,
membangun paket untuk setiap permintaan penggabungan dan mendorong ke master, asalkan ada baris tertentu dalam pesan komit,
mengirim paket bawaan ke umpan pribadi di Azure DevOps,
perakitan dokumentasi dan publikasi di GitLab Pages,
lencana!11

Persyaratan yang dijelaskan secara organik jatuh pada model pipa berikut:

Tahap 1 - perakitan
- Kami mengumpulkan kode, menerbitkan file keluaran sebagai artefak
Tahap 2 - pengujian
- Kami mendapatkan artefak dari tahap pembuatan, menjalankan pengujian, mengumpulkan data cakupan kode
Tahap 3 - Kirim
- Tugas 1 - buat paket nuget dan kirimkan ke Azure DevOps
- Tugas 2 - kami mengumpulkan situs dari xmldoc dalam kode sumber dan menerbitkannya di Halaman GitLab

Mari kita mulai!

Mengumpulkan konfigurasi

Mempersiapkan akun

Buat akun di Microsoft Azure
Pergi ke Azure DevOps
Kami membuat proyek baru
1. Nama - apapun
2. Visibilitas - apa saja
Ketika Anda mengklik tombol Buat, proyek akan dibuat dan Anda akan dialihkan ke halamannya. Di halaman ini, Anda dapat menonaktifkan fitur yang tidak perlu dengan masuk ke pengaturan proyek (tautan bawah di daftar di sebelah kiri -> Ikhtisar -> blok Layanan Azure DevOps)
Buka Atrifacts, klik Buat umpan
1. Masukkan nama sumber
2. Pilih visibilitas
3. Hapus centang Sertakan paket dari sumber umum umum, agar sumber tidak berubah menjadi klon dump nuget
Klik Sambungkan ke umpan, pilih Visual Studio, salin Sumber dari blok Penyiapan Mesin
Buka pengaturan akun, pilih Token Akses Pribadi
Buat token akses baru
1. Nama - sewenang-wenang
2. Organisasi - Saat Ini
3. Berlaku maksimal 1 tahun
4. Cakupan - Pengemasan/Baca & Tulis
Salin token yang dibuat - setelah jendela modal ditutup, nilainya tidak akan tersedia
Buka pengaturan repositori di GitLab, pilih pengaturan CI / CD
Perluas blok Variabel, tambahkan yang baru
1. Nama - apapun tanpa spasi (akan tersedia di command shell)
2. Nilai - token akses dari paragraf 9
3. Pilih variabel Mask

Ini melengkapi pra-konfigurasi.

Mempersiapkan kerangka konfigurasi

Secara default, konfigurasi CI/CD di GitLab menggunakan file tersebut .gitlab-ci.yml dari akar repositori. Anda dapat mengatur jalur sewenang-wenang ke file ini di pengaturan repositori, tetapi dalam hal ini tidak diperlukan.

Seperti yang Anda lihat dari ekstensi, file tersebut berisi konfigurasi dalam format YAML. Rincian dokumentasi kunci mana yang dapat dimuat di tingkat atas konfigurasi, dan di setiap tingkat bersarang.

Pertama, mari tambahkan tautan ke gambar buruh pelabuhan di file konfigurasi, di mana tugas akan dilakukan. Untuk ini kami menemukan Halaman gambar .Net Core di Docker Hub. Di GitHub ada panduan mendetail tentang gambar mana yang harus dipilih untuk berbagai tugas. Gambar dengan .Net Core 3.1 cocok untuk kita bangun, jadi jangan ragu untuk menambahkan baris pertama ke konfigurasi

image: mcr.microsoft.com/dotnet/core/sdk:3.1

Sekarang, saat pipa diluncurkan dari repositori gambar Microsoft, gambar yang ditentukan akan diunduh, di mana semua tugas dari konfigurasi akan dijalankan.

Langkah selanjutnya adalah menambahkan tahap'S. Secara default, GitLab mendefinisikan 5 tahapan:

.pre - dilakukan hingga semua tahapan,
.post - dilakukan setelah semua tahapan,
build - pertama setelah .pre panggung,
test - tahap kedua,
deploy - tahap ketiga.

Namun, tidak ada yang menghalangi Anda untuk mendeklarasikannya secara eksplisit. Urutan di mana langkah-langkah dicantumkan mempengaruhi urutan di mana mereka dilakukan. Untuk kelengkapan, mari kita tambahkan ke konfigurasi:

stages:
  - build
  - test
  - deploy

Untuk debugging, masuk akal untuk mendapatkan informasi tentang lingkungan tempat tugas dijalankan. Mari tambahkan satu set perintah global yang akan dieksekusi sebelum setiap tugas dengan before_script:

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

Tetap menambahkan setidaknya satu tugas sehingga ketika komit dikirim, pipa akan dimulai. Untuk saat ini, mari tambahkan tugas kosong untuk didemonstrasikan:

dummy job:
  script:
    - echo ok

Kami memulai validasi, kami mendapat pesan bahwa semuanya baik-baik saja, kami berkomitmen, kami mendorong, kami melihat hasilnya di situs ... Dan kami mendapatkan kesalahan skrip - bash: .PSVersion: command not found. apa?

Semuanya logis - secara default, pelari (bertanggung jawab untuk mengeksekusi skrip tugas dan disediakan oleh GitLab) digunakan bash untuk mengeksekusi perintah. Anda dapat memperbaikinya dengan secara eksplisit menentukan dalam deskripsi tugas tag apa yang harus dimiliki oleh pelari pipa pelaksana:

dummy job on windows:
  script:
    - echo ok
  tags:
    - windows

Besar! Pipa sekarang berjalan.

Seorang pembaca yang penuh perhatian, setelah mengulangi langkah-langkah yang ditunjukkan, akan melihat bahwa tugas tersebut telah selesai pada tahap tersebut test, meskipun kami tidak menentukan tahapannya. Seperti yang Anda duga test adalah langkah default.

Mari lanjutkan membuat kerangka konfigurasi dengan menambahkan semua tugas yang dijelaskan di atas:

build job:
  script:
    - echo "building..."
  tags:
    - windows
  stage: build

test and cover job:
  script:
    - echo "running tests and coverage analysis..."
  tags:
    - windows
  stage: test

pack and deploy job:
  script:
    - echo "packing and pushing to nuget..."
  tags:
    - windows
  stage: deploy

pages:
  script:
    - echo "creating docs..."
  tags:
    - windows
  stage: deploy

Kami mendapat saluran pipa yang tidak terlalu berfungsi, namun tetap benar.

Menyiapkan pemicu

Karena fakta bahwa tidak ada filter pemicu yang ditentukan untuk tugas apa pun, pipeline akan melakukannya sepenuhnya dieksekusi setiap kali komit didorong ke repositori. Karena ini bukan perilaku yang diinginkan secara umum, kami akan menyiapkan filter pemicu untuk tugas.

Filter dapat dikonfigurasi dalam dua format: hanya/kecuali и aturan. Secara singkat, only/except memungkinkan Anda mengonfigurasi filter berdasarkan pemicu (merge_request, misalnya - menyetel tugas untuk dieksekusi setiap kali permintaan tarik dibuat dan setiap kali komit dikirim ke cabang yang merupakan sumber dalam permintaan gabungan) dan nama cabang (termasuk menggunakan ekspresi reguler); rules memungkinkan Anda menyesuaikan serangkaian ketentuan dan, secara opsional, mengubah ketentuan pelaksanaan tugas tergantung pada keberhasilan tugas sebelumnya (when di GitLab CI/CD).

Mari kita ingat serangkaian persyaratan - perakitan dan pengujian hanya untuk permintaan penggabungan, pengemasan, dan pengiriman ke Azure DevOps - untuk permintaan penggabungan dan push ke master, pembuatan dokumentasi - untuk push ke master.

Pertama, mari siapkan tugas pembuatan kode dengan menambahkan aturan yang hanya diaktifkan pada permintaan gabungan:

build job:
  # snip
  only:
    - merge_request

Sekarang mari siapkan tugas pengemasan untuk mengaktifkan permintaan penggabungan dan menambahkan komit ke master:

pack and deploy job:
  # snip
  only:
    - merge_request
    - master

Seperti yang Anda lihat, semuanya sederhana dan lugas.

Anda juga dapat menyetel tugas untuk diaktifkan hanya jika permintaan penggabungan dibuat dengan cabang target atau sumber tertentu:

  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

Dalam kondisi, Anda dapat menggunakan variabel yang tercantum di sini; aturan rules tidak sesuai dengan aturan only/except.

Mengonfigurasi Penyimpanan Artefak

Selama tugas build job kita akan membuat artefak yang dapat digunakan kembali dalam tugas selanjutnya. Untuk melakukan ini, Anda perlu menambahkan jalur ke konfigurasi tugas, file yang akan Anda simpan dan gunakan kembali dalam tugas berikut, ke tombol artifacts:

build job:
  # snip
  artifacts:
    paths:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

Path mendukung wildcard, yang tentunya membuatnya lebih mudah untuk diatur.

Jika suatu tugas membuat artefak, maka setiap tugas berikutnya akan dapat mengaksesnya - mereka akan ditempatkan di sepanjang jalur yang sama relatif terhadap root repositori yang dikumpulkan dari tugas asli. Artefak juga tersedia untuk diunduh di situs.

Sekarang kita memiliki kerangka konfigurasi yang siap (dan diuji), kita dapat melanjutkan untuk benar-benar menulis skrip untuk tugas.

Kami menulis skrip

Mungkin, pada suatu waktu, di galaksi yang sangat jauh, membangun proyek (termasuk yang ada di .net) dari baris perintah sangat merepotkan. Sekarang Anda dapat membuat, menguji, dan menerbitkan proyek dalam 3 tim:

dotnet build
dotnet test
dotnet pack

Secara alami, ada beberapa nuansa yang karenanya kami akan memperumit perintah.

Kami ingin build rilis, bukan build debug, jadi kami menambahkan ke setiap perintah -c Release
Saat menguji, kami ingin mengumpulkan data cakupan kode, jadi kami perlu menyertakan penganalisa cakupan di pustaka pengujian:
1. Tambahkan paket ke semua pustaka pengujian coverlet.msbuild: dotnet add package coverlet.msbuild dari folder proyek
2. Tambahkan ke perintah uji coba /p:CollectCoverage=true
3. Tambahkan kunci ke konfigurasi tugas pengujian untuk mendapatkan hasil cakupan (lihat di bawah)
Saat mengemas kode ke dalam paket nuget, setel direktori keluaran untuk paket: -o .

Mengumpulkan data cakupan kode

Setelah menjalankan tes, Coverlet mencetak statistik lari ke konsol:

Calculating coverage result...
  Generating report 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Module      | Line   | Branch | Method |
+-------------+--------+--------+--------+
| project 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| project 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| project 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Line   | Branch | Method |
+---------+--------+--------+--------+
| Total   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Average | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

GitLab memungkinkan Anda menentukan ekspresi reguler untuk mendapatkan statistik, yang kemudian dapat diperoleh dalam bentuk lencana. Ekspresi reguler ditentukan dalam pengaturan tugas dengan kunci coverage; ekspresi harus berisi grup tangkap, yang nilainya akan diteruskan ke lencana:

test and cover job:
  # snip
  coverage: /|s*Totals*|s*(d+[,.]d+%)/

Di sini kami mendapatkan statistik dari garis dengan cakupan garis total.

Publikasikan paket dan dokumentasi

Kedua tindakan tersebut dijadwalkan untuk tahap terakhir dari pipeline - karena perakitan dan pengujian telah berlalu, kami dapat membagikan perkembangan kami dengan dunia.

Pertama, pertimbangkan untuk memublikasikan ke sumber paket:

Jika proyek tidak memiliki file konfigurasi nuget (nuget.config), buat yang baru: dotnet new nugetconfig

Untuk apa: image mungkin tidak memiliki akses tulis ke konfigurasi global (pengguna dan mesin). Agar tidak menemukan kesalahan, kami cukup membuat konfigurasi lokal baru dan bekerja dengannya.
Mari tambahkan sumber paket baru ke konfigurasi lokal: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - nama sumber lokal, tidak kritis
2. url - URL sumber dari tahap "Mempersiapkan akun", hal.6
3. organization - nama organisasi di Azure DevOps
4. gitlab variable - nama variabel dengan token akses yang ditambahkan ke GitLab ("Mempersiapkan akun", hal. 11). Secara alami, dalam format $variableName
5. -StorePasswordInClearText - peretasan untuk mem-bypass kesalahan akses ditolak (Saya bukan orang pertama yang menginjak penggaruk ini)
6. Jika terjadi kesalahan, mungkin berguna untuk ditambahkan -verbosity detailed
Mengirim paket ke sumber: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Kami mengirim semua paket dari direktori saat ini, jadi *.nupkg.
2. name - dari langkah di atas.
3. key - setiap baris. Di Azure DevOps, di jendela Sambungkan ke umpan, contohnya selalu berupa baris az.
4. -skipduplicate - saat mencoba mengirim paket yang sudah ada tanpa kunci ini, sumber akan mengembalikan kesalahan 409 Conflict; dengan kunci, pengiriman akan dilewati.

Sekarang mari kita siapkan pembuatan dokumentasi:

Pertama, di repositori, di cabang master, kami menginisialisasi proyek docfx. Untuk melakukan ini, jalankan perintah dari root docfx init dan secara interaktif mengatur parameter kunci untuk membangun dokumentasi. Deskripsi terperinci tentang penyiapan proyek minimum di sini.
1. Saat mengonfigurasi, penting untuk menentukan direktori keluaran ..public - GitLab secara default mengambil konten folder publik di root repositori sebagai sumber Halaman. Karena proyek akan ditempatkan di folder yang bersarang di repositori - tambahkan output ke level atas di jalur.
Mari dorong perubahan ke GitLab.
Tambahkan tugas ke konfigurasi pipa pages (kata yang dicadangkan untuk tugas penerbitan situs di GitLab Pages):
1. Naskah:
  1. nuget install docfx.console -version 2.51.0 - instal docfx; versi ditentukan untuk memastikan bahwa jalur penginstalan paket sudah benar.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - mengumpulkan dokumentasi
2. Artefak simpul:

pages:
  # snip
  artifacts:
    paths:
      - public

Penyimpangan liris tentang docfx

Sebelumnya, saat menyiapkan proyek, saya menentukan sumber kode untuk dokumentasi sebagai file solusi. Kerugian utamanya adalah dokumentasi juga dibuat untuk proyek uji. Jika tidak diperlukan, Anda dapat menyetel nilai ini ke node metadata.src:

{
  "metadata": [
    {
      "src": [
        {
          "src": "../",
          "files": [
            "**/*.csproj"
          ],
          "exclude":[
            "*.tests*/**"
          ]
        }
      ],
      // --- snip ---
    },
    // --- snip ---
  ],
  // --- snip ---
}

metadata.src.src: "../" - kita naik satu tingkat relatif terhadap lokasi docfx.json, Karena dalam pola, mencari di pohon direktori tidak berfungsi.
metadata.src.files: ["**/*.csproj"] - pola global, kami mengumpulkan semua proyek C # dari semua direktori.
metadata.src.exclude: ["*.tests*/**"] - pola global, kecualikan semuanya dari folder dengan .tests Dalam judul

Subtotal

Konfigurasi sederhana seperti itu dapat dibuat hanya dalam setengah jam dan beberapa cangkir kopi, yang memungkinkan Anda untuk memeriksa apakah kode telah dibuat dan lulus tes, membuat paket baru, memperbarui dokumentasi, dan menyenangkan mata dengan indah lencana di README proyek dengan setiap permintaan penggabungan dan pengiriman ke master.

Final .gitlab-ci.yml

image: mcr.microsoft.com/dotnet/core/sdk:3.1

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

stages:
  - build
  - test
  - deploy

build job:
  stage: build
  script:
    - dotnet build -c Release
  tags:
    - windows
  only:
    - merge_requests
    - master
  artifacts:
    paths:
      - your/path/to/binaries

test and cover job:
  stage: test
  tags:
    - windows
  script:
    - dotnet test -c Release /p:CollectCoverage=true
  coverage: /|s*Totals*|s*(d+[,.]d+%)/
  only:
    - merge_requests
    - master

pack and deploy job:
  stage: deploy
  tags:
    - windows
  script:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  only:
    - master

pages:
  tags:
    - windows
  stage: deploy
  script:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

Berbicara tentang lencana

Karena mereka, semuanya dimulai!

Lencana dengan status pipeline dan cakupan kode tersedia di GitLab di pengaturan CI/CD di blok pipeline Gtntral:

Saya membuat lencana dengan tautan ke dokumentasi di platform Perisai.io - semuanya cukup mudah di sana, Anda dapat membuat lencana Anda sendiri dan menerimanya menggunakan permintaan.

![Пример с Shields.io](https://img.shields.io/badge/custom-badge-blue)

Artefak Azure DevOps juga memungkinkan Anda membuat lencana untuk paket dengan versi terbaru. Untuk melakukan ini, di sumber di situs Azure DevOps, Anda perlu mengklik Buat lencana untuk paket yang dipilih dan menyalin markup markdown:

Menambah keindahan

Menyoroti Fragmen Konfigurasi Umum

Saat menulis konfigurasi dan menelusuri dokumentasi, saya menemukan fitur menarik dari YAML - menggunakan kembali fragmen.

Seperti yang Anda lihat dari pengaturan tugas, semuanya memerlukan tag windows di pelari, dan dipicu saat permintaan penggabungan dikirim ke master/dibuat (kecuali dokumentasi). Mari tambahkan ini ke fragmen yang akan kita gunakan kembali:

.common_tags: &common_tags
  tags:
    - windows
.common_only: &common_only
  only:
    - merge_requests
    - master

Dan sekarang kita bisa menyisipkan fragmen yang dideklarasikan sebelumnya dalam deskripsi tugas:

build job:
  <<: *common_tags
  <<: *common_only

Nama fragmen harus diawali dengan titik, agar tidak diartikan sebagai tugas.

Versi paket

Saat membuat paket, kompiler memeriksa sakelar baris perintah, dan jika tidak ada, file proyek; ketika menemukan simpul Versi, ia mengambil nilainya sebagai versi dari paket yang sedang dibangun. Ternyata untuk membuat paket dengan versi baru, Anda perlu memperbaruinya di file proyek atau meneruskannya sebagai argumen baris perintah.

Mari tambahkan satu Daftar Keinginan lagi - biarkan dua angka minor dalam versi menjadi tahun dan tanggal pembuatan paket, dan tambahkan versi prarilis. Tentu saja, Anda dapat menambahkan data ini ke file proyek dan memeriksanya sebelum setiap pengiriman - tetapi Anda juga dapat melakukannya di saluran pipa, mengumpulkan versi paket dari konteks dan meneruskannya melalui argumen baris perintah.

Mari kita setuju jika pesan komit berisi baris seperti release (v./ver./version) <version number> (rev./revision <revision>)?, lalu kami akan mengambil versi paket dari baris ini, melengkapinya dengan tanggal saat ini dan meneruskannya sebagai argumen ke perintah dotnet pack. Jika tidak ada antrean, kami tidak akan mengambil paketnya.

Skrip berikut memecahkan masalah ini:

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

Menambahkan skrip ke tugas pack and deploy job dan amati perakitan paket secara ketat di hadapan string yang diberikan dalam pesan komit.

Total

Setelah menghabiskan sekitar setengah jam atau satu jam menulis konfigurasi, men-debug di powershell lokal dan, mungkin, beberapa peluncuran yang gagal, kami mendapat konfigurasi sederhana untuk mengotomatiskan tugas-tugas rutin.

Tentu saja, GitLab CI / CD jauh lebih luas dan beragam daripada yang terlihat setelah membaca panduan ini - itu tidak benar sama sekali. Di sana bahkan Auto DevOps adalahmengizinkan

mendeteksi, membuat, menguji, menerapkan, dan memantau aplikasi Anda secara otomatis

Sekarang rencananya adalah mengonfigurasi pipa untuk menerapkan aplikasi ke Azure, menggunakan Pulumi dan secara otomatis menentukan lingkungan target, yang akan dibahas di artikel berikutnya.

Sumber: www.habr.com

Panduan untuk CI/CD di GitLab untuk (hampir) pemula mutlak