🥇Vodič za CI/CD u GitLabu za (gotovo) potpune novajlije

Ili kako nabaviti lijepe bedževe za svoj projekt za jedan večer jednostavnog kodiranja

Vjerojatno svaki developer koji ima barem jedan pet projekt u jednom trenutku poželi lijepe bedževe sa statusima, pokrivenošću koda, verzijama paketa u nugetu… I taj me želja nagnala na pisanje ovog članka. Tijekom pripreme za njegovo pisanje, nabavio sam ovakvu ljepotu u jednom od svojih projekata:

U članku će biti razmotrena osnovna postavka kontinuirane integracije i isporuke za projekt knjižnice klasa na .Net Core u GitLab-u, s objavljivanjem dokumentacije na GitLab Pages i slanjem sastavljenih paketa u privatni feed u Azure DevOps.

Kao razvojno okruženje korišten je VS Code s ekstenzijom GitLab Workflow (za validaciju datoteke postavki direktno iz razvojne okoline).

Kratki uvod

CI - to je kada si upravo pushao, a klijentu je već sve srušeno?

Što je CI/CD i zašto je potrebno - to se lako može naći na internetu. Potpunu dokumentaciju za postavljanje pipeline-a u GitLab-u također nije teško pronaći . Ovdje ću ukratko i, koliko je moguće, bez grešaka opisati proces rada sustava iz ptičje perspektive:developer šalje commit u repozitorij, stvara merge request putem web stranice,

ili na neki drugi način eksplicitno ili implicite pokreće pipeline iz konfiguracije se biru svi zadaci čiji uvjeti omogućuju njihovo pokretanje u ovom kontekstu,,
zadaci se organiziraju prema svojim fazama,
faze se uzastopno izvršavaju - tj.
paralelno izvršavaju se svi zadaci ove faze, ako faza završi neuspješno (tj. ako barem jedan od zadataka faze završi neuspješno) - pipeline se zaustavlja (
gotovo uvijekako su sve faze završene uspješno, pipeline se smatra uspješno završenim.),
Tako imamo:

pipeline - skup zadataka organiziranih u faze, u kojem se može sastaviti, testirati, zapakirati kod, rasporediti gotovu verziju u oblacima, i slično,

faza (
stage) - jedinica organizacije pipeline-a, sadrži 1+ zadatak,zadak (
job) - jedinica rada u pipeline-u. Sastoji se od skripte (obavezno), uvjeta pokretanja, postavki objavljivanja/keširanja artefakata i mnogih drugih.) — jedinica rada u radnom postupku. Sastoji se od skripte (obavezno), uvjeta pokretanja, postavki objave/keširanja artefakata i mnogo toga drugog.

U skladu s tim, cilj prilikom postavljanja CI/CD-a je stvoriti skup zadataka koji implementiraju sve potrebne radnje za izgradnju, testiranje i objavu koda i artefakata.

Prije početka: zašto?

Zašto GitLab?

Zato što kada se pojavila potreba za privatnim repozitorijima za pet-projekte, na GitHubu su bili plaćeni, a ja sam bio škrt. Repozitoriji su postali besplatni, ali to za mene nije bio dovoljno dobar razlog za premještanje na GitHub.

Zašto ne Azure DevOps Pipelines?

Jer je postavljanje elementarno — čak nisu potrebna znanja o komandnoj liniji. Integracija s vanjskim provajderima git — u nekoliko klikova, uvoz SSH ključeva za slanje commit-a u repozitorij — također, pipeline se lako postavlja čak i bez predloška.

Polazna pozicija: što imamo i što želimo

Imamo:

repozitorij u GitLab-u.

Želimo:

automatsku izgradnju i testiranje za svaki merge request,
izgradnju paketa za svaki merge request i push u master pod uvjetom da u poruci commita postoji određeni niz,
slanje prikupljenih paketa u privatni feed u Azure DevOps-u,
izgradnju dokumentacije i objavu na GitLab Pages,
bedževe!11

Opisani zahtjevi skladno se uklapaju u sljedeći model pipeline-a:

Faza 1 — izgradnja
- Izrađujemo kod, izlazne datoteke objavljujemo kao artefakte
Faza 2 — testiranje
- Dobivamo artefakte iz faze izgradnje, provodimo testove, prikupljamo podatke o pokrivenosti koda
Faza 3 — slanje
- Zadatak 1 — izrađujemo nuget paket i šaljemo u Azure DevOps
- Zadatak 2 — izrađujemo stranicu iz xmldoc-a u izvornom kodu i objavljujemo na GitLab Pages

Krenimo!

Pripremamo konfiguraciju

Pripremamo račune

Otvaramo račun u Microsoft Azure
Prelazimo u Azure DevOps
Stvaramo novi projekt
1. Ime — bilo koje
2. Vidljivost — bilo koja
Kada pritisnete dugme Create, projekt će biti stvoren i bit će izvršeno preusmjeravanje na njegovu stranicu. Na ovoj stranici možete isključiti nepotrebne mogućnosti, odlaskom u postavke projekta (donja veza u lijevom popisu -> Overview -> blok Azure DevOps Services)
Prelazimo u Atrifacts, kliknemo Create feed
1. Unosimo ime izvora
2. Biramo vidljivost
3. Uklanjamo kvačicu Include packages from common public sources, kako izvor ne bi postao smeće klon nuget-a
Kliknemo Connect to feed, biramo Visual Studio, iz bloka Machine Setup kopiramo Source
Idemo u postavke računa, biramo Personal Access Token
Stvaramo novi token za pristup
1. Ime — proizvoljno
2. Organizacija — trenutna
3. Trajanje - najviše 1 godina
4. Područje primjene (scope) - Pakiranje / Čitanje i pisanje
Kopiramo stvoreni token - nakon zatvaranja modalnog prozora vrijednost neće biti dostupna
Idemo u postavke repozitorija u GitLab-u, biramo CI / CD postavke
Proširujemo blok Varijable, dodajemo novu
1. Ime - bilo koje bez razmaka (bit će dostupno u komandnom okruženju)
2. Vrijednost - token za pristup iz točke 9
3. Biramo Mask variable

S ovom preliminarna konfiguracija je završena.

Pripremamo kostur konfiguracije

Zadano, za konfiguriranje CI / CD u GitLab-u koristi se datoteka .gitlab-ci.yml iz korijena repozitorija. Možete postaviti proizvoljnu putanju do ove datoteke u postavkama repozitorija, ali u ovom slučaju to nije potrebno.

Kao što se može vidjeti iz ekstenzije, datoteka sadrži konfiguraciju u formatu YAML. U dokumentaciji je detaljno opisano koji ključevi mogu biti sadržani na vrhunskom nivou konfiguracije, kao i na svakom od ugniježdenih nivoa.

Prvo dodamo u konfiguracijsku datoteku vezu na docker-sliku u kojoj će se izvršavati zadatci. Za to nalazimo stranicu slika .Net Core u Docker Hub-u. U GitHub ima detaljan vodič o tome koju sliku odabrati za različite zadatke. Nama za izradu odgovara slika s .Net Core 3.1, stoga slobodno dodajemo prvu liniju u konfiguraciju

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

Sada će se prilikom pokretanja pipeline-a s repozitorija slike Microsoft preuzeti navedena slika, u kojoj će se izvršavati svi zadaci iz konfiguracije.

Sljedeći korak - dodati ) - jedinica organizacije pipeline-a, sadrži 1+ zadatak,etape. Zadano GitLab određuje 5 etapa:

.pre - izvršava se prije svih etapa,
.post - izvršava se nakon svih etapa,
build - prvi nakon .pre etape,
test - druga etapa,
deploy - treća etapa.

Ništa ne sprječava da ih izričito navedemo. Redoslijed u kojem su navedene etape utječe na redoslijed njihova izvršenja. Za potpunost predstavljanja, dodajmo u konfiguraciju:

stages:
  - build
  - test
  - deploy

Za debagiranje ima smisla dobiti informacije o okruženju u kojem se izvršavaju zadatci. Dodajmo globalni skup komandi koje će se izvršavati prije svake zadaće, pomoću before_script:

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

Preostaje dodati barem jedan zadatak kako bi se pipeline pokrenuo prilikom slanja commitova. Za sada dodajmo prazni zadatak za demonstraciju:

dummy job:
  script:
    - echo ok

Pokrećemo validaciju, dobivamo poruku da je sve u redu, komitiramo, šaljemo, gledamo rezultate na stranici… I dobijamo grešku skripte — bash: .PSVersion: naredba nije pronađena. WTF?

Sve je logično — prema zadanim postavkama runneri (koji su zaduženi za izvođenje skripti zadataka, a pruža ih GitLab) koriste bash za izvršavanje komandi. Ovo se može popraviti, jasno navodeći u opisu zadatka koji tagovi bi trebali biti kod izvođenja pipeline runnera:

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

Odlično! Sada se pipeline izvršava.

Pažljiv čitatelj, ponovivši navedene korake, primijetit će da je zadatak izvršen u etapi test, iako nismo naveli etapu. Kako se može naslutiti, test je etapa prema zadanim postavkama.

Nastavimo s izradom skeleta konfiguracije, dodajući sve zadatke opisane iznad:

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

Dobili smo ne osobito funkcionalan, ali ipak ispravan pipeline.

Postavljanje okidača

Budući da za nijedan od zadataka nisu navedeni okidači filtriranja, pipeline će se Potpuno. izvršavati pri svakoj poslanici commit-a u repozitorij. Budući da to nije željeno ponašanje u općem slučaju, postavit ćemo filtre za okidače za zadatke.

Filtri se mogu postaviti u dva formata: only/except i rules. Ukratko, only/except omogućuje postavljanje filtara prema okidačima (merge_request, na primjer — postavlja zadatak da se izvršava prilikom svakog kreiranja zahtjeva za spajanje i prilikom svake poslanice commit-a u granu koja je izvorna u zahtjevu za spajanje) i imenima grana (uključujući korištenje regularnih izraza); rules omogućuje postavljanje skupa uvjeta i, opcionalno, promjenu uvjeta izvršavanja zadatka ovisno o uspjehu prethodnih zadataka (when u GitLab CI/CD).

Podsjetimo se skupa zahtjeva — izgradnja i testiranje samo za merge request, pakiranje i slanje u Azure DevOps — za merge request i push-ove u master, generiranje dokumentacije — za push-ove u master.

Za početak, postavimo zadatak izgradnje koda, dodajući pravilo okidača samo za merge request:

build job:
  # obrezano
  only:
    - merge_request

Sada postavimo zadatak pakiranja na aktivacije na merge request i dodavanje commit-a u master:

pakirajte i objavite posao:
  # skraćeno
  samo:
    - merge_request
    - master

Kao što se može vidjeti, sve je jednostavno i izravno.

Možete također postaviti zadatak da se aktivira samo ako je stvoren merge request s određenom odredišnom ili izvorno granom:

  pravila:
    - ako: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

U uvjetima možete koristiti ovdje navedene varijable; pravila rules nisu kompatibilna s pravilima only/except.

Postavka spremanja artefakata

Tijekom izvršavanja zadatka izrada posla bit će stvoreni artefakti izrade koji se mogu ponovno koristiti u sljedećim zadacima. Za to je potrebno dodati putanje u konfiguraciju zadatka, datoteke koje treba spremiti i ponovno koristiti u sljedećim zadacima, u ključeve artefakti:

izrada posla:
  # skraćeno
  artefakti:
    putanje:
      - putanja/do/artefakata/izrade
      - druga/putanja
      - MyCoolLib.*/bin/Release/*

Putanje podržavaju wildcards, što definitivno olakšava njihovo postavljanje.

Ako zadatak stvara artefakte, tada će svaki sljedeći zadatak moći pristupiti njima — bit će smješteni na istim putanjama u odnosu na korijen repozitorija, kao što su prikupljeni iz izvorne zadaće. Također, artefakti su dostupni za preuzimanje na webu.

Sada kada imamo gotovu (i provjerenu) strukturu konfiguracije, možemo preći na actually pisanje skripti za zadatke.

Pišemo skripte

Možda je nekoć, u dalekoj galaksiji, izgradnja projekata (uključujući i na .net) iz naredbenog retka bila bolna. Sada se izgradnja, testiranje i objavljivanje projekta može obaviti u 3 naredbe:

dotnet build
dotnet test
dotnet pack

Naravno, postoje neki detalji zbog kojih ćemo malo zakomplicirati naredbe.

Želimo proizvodnu, a ne razvojnu izgradnju, pa dodajemo -c Release
Tijekom testiranja želimo prikupljati podatke o pokrivenosti koda, stoga će biti potrebno uključiti analizator pokrivenosti u testne biblioteke:
1. U sve testne biblioteke treba dodati paket coverlet.msbuild: dotnet add package coverlet.msbuild iz mape projekta
2. U naredbu za pokretanje testova dodamo /p:CollectCoverage=true
3. U konfiguraciju zadatka testiranja dodamo ključ za dobivanje rezultata pokrivenosti (vidi dolje)
Prilikom pakiranja koda u nuget pakete postavit ćemo izlazni direktorij za pakete: -o .

Prikupljamo podatke o pokrivenosti koda

Coverlet nakon pokretanja testova ispisuje statistiku o izvođenju u konzolu:

Izračunavanje rezultata pokrivenosti...
  Generiranje izvještaja 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Modul       | Linija | Grana   | Metoda |
+-------------+--------+--------+--------+
| projekt 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| projekt 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| projekt 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Linija | Grana   | Metoda |
+---------+--------+--------+--------+
| Ukupno  | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Prosjek | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

GitLab omogućava definiranje regularnog izraza za dobivanje statistike, koju zatim možete dobiti u obliku bedža. Regularni izraz se definira u postavkama zadatka s ključem coverage; izraz mora sadržavati capture-grupu, čija će vrijednost biti prenesena u bedž:

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

Ovdje dobivamo statistiku iz reda s ukupnom pokrivenošću po linijama.

Objavljujemo pakete i dokumentaciju

Obje akcije su nam dodijeljene na posljednjem koraku pipeline-a — budući da su kompilacija i testovi prošli, možemo podijeliti svoja postignuća sa svijetom.

Za početak razmotrimo objavljivanje u izvor paketa:

Ako u projektu ne postoji konfiguracijska datoteka nuget (nuget.config), kreirat ćemo novu: dotnet new nugetconfig
Zašto: u slici može biti zabranjen upis u globalne (korisničke i mašinske) konfiguracije. Da ne bismo dobili greške, jednostavno ćemo kreirati novu lokalnu konfiguraciju i raditi s njom.
Dodajemo novi izvor paketa u lokalnu konfiguraciju: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. ime — lokalno ime izvora, nije važno
2. url — URL izvora iz koraka "Pripremamo račune", točka 6
3. organization — naziv organizacije u Azure DevOps
4. gitlab variable — naziv varijable s tokenom pristupa, dodan u GitLab ("Pripremamo račune", točka 11). Naravno, u formatu $variableName
5. -StorePasswordInClearText — hack za zaobilaženje greške odbijanja pristupa (nisam prvi koji je naišao na ove prepreke.)
6. U slučaju grešaka može biti korisno dodati -verbosity detailed
Šaljemo paket u izvor: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Šaljemo sve pakete iz trenutnog direktorija, zato *.nupkg.
2. ime — iz koraka iznad.
3. key — bilo koji niz. U Azure DevOpsu u prozoru Zahtijevaj povezivanje s feed-om uvijek kao primjer daju niz az.
4. -skipduplicate — prilikom pokušaja slanja već postojećeg paketa bez ovog ključa, izvor će vratiti grešku 409 Sukob; s ključem slanje će biti propušteno.

Sada ćemo postaviti izradu dokumentacije:

Za početak, u repozitoriju, na grani master, inicijaliziramo projekt docfx. Za to iz korijena treba izvršiti naredbu docfx init i u interaktivnom načinu postaviti ključne parametre za izradu dokumentacije. Detaljan opis minimalne konfiguracije projekta ovdje.
1. Pri postavkama je važno navesti izlazni direktorij ..public — GitLab prema zadanim postavkama uzima sadržaj mape public u korijenu repozitorija kao izvor za stranice. Budući da će projekt biti smješten unutar mape u repozitoriju — dodajemo izlaznu putanju na razinu više.
Poslat ćemo promjene u GitLab.
U konfiguraciju pipelinea dodajemo zadatak pages (rezervirana riječ za zadatke objave stranica u GitLab Pages):
1. Skripta:
  1. nuget install docfx.console -version 2.51.0 — instalira docfx; verzija je navedena za jamstvo točnosti putanja instalacije paketa.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json — sastavljamo dokumentaciju
2. Čvor artifacts:

pages:
  # snip
  artifacts:
    paths:
      - public

Lirski odmak o docfx

Ranije sam pri postavljanju projekta navodio izvorni kod za dokumentaciju kao datoteku rješenja. Glavni nedostatak — dokumentacija se stvara i za testne projekte. U slučaju da to nije potrebno, može se postaviti takva vrijednost za čvor metadata.src:

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

metadata.src.src: "..\/" — izlazimo na razinu više u odnosu na lokaciju docfx.json, jer u obrascima ne radi pretraživanje prema gore po stablu direktorija.
metadata.src.files: ["**\/*.csproj"] — globalni uzorak, prikupljamo sve C# projekte iz svih direktorija.
metadata.src.exclude: ["*.tests*\/**"] — globalni uzorak, isključujemo sve iz mapa s .tests u nazivu

Međusobni zaključak

Ovu jednostavnu konfiguraciju može se sastaviti doslovno za pola sata i nekoliko šalica kave, koja će omogućiti provjeru da se kod sastavlja i testovi prolaze pri svakom zahtjevu za spajanje i slanjem u master, prikupljati novi paket, ažurirati dokumentaciju i radovati oči lijepim bedževima u README projektu.

Zaključni .gitlab-ci.yml

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

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

stupnjevi:
  - build
  - test
  - deploy

posao izgradnje:
  faza: build
  skripta:
    - dotnet build -c Release
  oznake:
    - windows
  samo:
    - merge_requests
    - master
  artefakti:
    putanje:
      - vaš/path/do/binaries

test i pokriće posao:
  faza: test
  oznake:
    - windows
  skripta:
    - dotnet test -c Release /p:CollectCoverage=true
  pokriće: /|s*Totals*|s*(d+[,.]d+%) /
  samo:
    - merge_requests
    - master

pakiraj i objavi posao:
  faza: deploy
  oznake:
    - windows
  skripta:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/vaša-organizacija/_packaging/vaša-hrana/nuget/v3/index.json -username vaša-organizacija -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  samo:
    - master

stranice:
  oznake:
    - windows
  faza: deploy
  skripta:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artefakti:
    putanje:
      - javno
  samo:
    - master

Usput o oznakama

Zbog njih je sve ovo i započeto!

Oznake sa statusima pipeline-a i pokrivenosti koda dostupne su u GitLab-u u postavkama CI/CD u odjeljku Gtntral pipelines:

Oznaku sa linkom na dokumentaciju sam stvorio na platformi Shields.io — tamo je sve prilično jednostavno, možete stvoriti svoju oznaku i dobiti ju putem zahtjeva.

![Primjer sa Shields.io](https://img.shields.io/badge/custom-badge-blue)

Azure DevOps Artifacts također omogućuje stvaranje oznaka za pakete s trenutnom verzijom. Za to u izvoru na web stranici Azure DevOps potrebno je pritisnuti Create badge kod odabranog paketa i kopirati markdown oznaku:

Dodajemo ljepotu

Izdvajamo zajedničke fragmente konfiguracije

Tokom pisanja konfiguracije i pretraživanja dokumentacije, naišao sam na zanimljivu mogućnost YAML-a — ponovo korištenje fragmenata.

Kao što se može vidjeti iz postavki zadataka, svi oni zahtijevaju prisutnost oznake windows na runner-u, i aktiviraju se prilikom slanja u master/kreiranja zahtjeva za spajanje (osim dokumentacije). Dodajmo to u fragment koji ćemo ponovo koristiti:

.common_tags: &common_tags
  oznake:
    - windows
.common_only: &common_only
  samo:
    - merge_requests
    - master

I sada u opisu zadatka možemo umetnuti ranije definirani fragment:

posao izgradnje:
  <<: *common_tags
  <<: *common_only

Nazivi fragmenata moraju počinjati točkom, kako ne bi bili interpretirani kao zadatak.

Verzioniranje paketa

Kada se kreira paket, kompajler provjerava ključeve naredbenog retka, a u njihovom odsustvu - datoteke projekata; pronašavši čvor Version, uzima njegovu vrijednost kao verziju paketa koji se gradi. Dakle, da bi se izgradio paket s novom verzijom, potrebno je ili ažurirati je u datoteci projekta, ili je proslijediti kao argument naredbenog retka.

Dodajmo još jednu želju - neka donja dva broja u verziji budu godina i datum izrade paketa, i dodajmo predizdanja. Ove podatke možemo dodati u datoteku projekta i provjeravati prije svake poslane verzije, naravno - ali to možemo učiniti i u pipelineu, prikupljajući verziju paketa iz konteksta i prosljeđujući je kroz argument naredbenog retka.

Dogovorimo se da ako u poruci commita postoji redak u obliku release (v.\/ver.\/version) <broj verzije> (rev.\/revizija <revizija>)?, tada ćemo iz te строки uzeti verziju paketa, dopuniti je trenutnim datumom i proslijediti kao argument komandi dotnet pack. U odsustvu te rečenice - jednostavno nećemo sastaviti paket.

Ovu zadaću rješava sljedeći skript:

# регулярное выражение для поиска строки с версией
$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

Dodajemo skript u zadatak pack and deploy job i promatramo izradu paketa strogo uz prisutnost zadane rečenice u poruci commita.

U konačnici

Uloživši otprilike pola sata do sat vremena u pisanje konfiguracije, debagiranje u lokalnom PowerShellu i, možda, nekoliko neuspješnih pokretanja, dobili smo jednostavnu konfiguraciju za automatizaciju rutinskih zadataka.

Naravno, GitLab CI/CD je mnogo opsežniji i raznolikiji nego što se može činiti nakon čitanja ovog vodiča - to uopće nije tako. Tamo čak i Auto DevOps postoji, što omogućava

automatsko otkrivanje, izradu, testiranje, implementaciju i praćenje vaših aplikacija

Sada su u planu - konfigurirati pipeline za implementaciju aplikacija u Azure, koristeći Pulumi i automatsko određivanje ciljnog okruženja, što će biti obrađeno u sljedećem članku.

Izvor: habr.com