🥇Sprievodca CI/CD v GitLab pre (takmer) absolútnych nováčikov

Alebo ako získať krásne odznaky pre svoj projekt za jeden večer jednoduchého kódovania

Pravdepodobne každého vývojára, ktorý má aspoň jeden pet projekt v určitom okamihu, svrbí krásne odznaky so statusmi, pokrytím kódu, verziami balíkov v nuget ... A toto svrbenie ma priviedlo k napísaniu tohto článku. V rámci prípravy na jeho písanie som v jednom z mojich projektov získal túto krásu:

Tento článok vás prevedie základným nastavením nepretržitej integrácie a doručovania pre projekt knižnice tried .Net Core v GitLab, publikovaním dokumentácie na GitLab Pages a posúvaním vytvorených balíkov do súkromného informačného kanála v Azure DevOps.

Ako vývojové prostredie s rozšírením bol použitý VS Code Pracovný postup GitLab (na overenie súboru nastavení priamo z vývojového prostredia).

Stručný úvod

CD - je to, keď ste práve zatlačili a všetko už padlo na klienta?

Čo je CI / CD a prečo to potrebujete - môžete si to ľahko vygoogliť. Nájdite kompletnú dokumentáciu o konfigurácii kanálov v GitLab tiež ľahké. Tu stručne a pokiaľ možno bez nedostatkov popíšem proces systému z vtáčej perspektívy:

vývojár odošle potvrdenie do úložiska, vytvorí žiadosť o zlúčenie prostredníctvom lokality, alebo nejakým iným spôsobom explicitne alebo implicitne spúšťa plynovod,
všetky úlohy sa vyberajú z konfigurácie, ktorej podmienky umožňujú ich spustenie v danom kontexte,
úlohy sú usporiadané podľa ich etáp,
etapy sa vykonávajú postupne - t.j. paralelné všetky úlohy tejto fázy sú splnené,
ak etapa zlyhá (t. j. zlyhá aspoň jedna z úloh etapy), potrubie sa zastaví (takmer vždy),
ak sú všetky etapy úspešne dokončené, potrubie sa považuje za úspešné.

Máme teda:

pipeline – súbor úloh organizovaných do etáp, v ktorých môžete zostavovať, testovať, baliť kód, nasadzovať hotovú zostavu do cloudovej služby atď.,
štádium (stupeň) — organizačná jednotka potrubia, obsahuje 1+ úlohu,
úloha (zamestnania) je jednotka práce v potrubí. Pozostáva zo skriptu (povinného), podmienok spustenia, nastavení publikovania/ukladania artefaktov do vyrovnávacej pamäte a mnohých ďalších.

Úloha pri nastavovaní CI / CD teda spočíva v vytvorení súboru úloh, ktoré implementujú všetky potrebné akcie na vytváranie, testovanie a publikovanie kódu a artefaktov.

Pred začatím: prečo?

Prečo práve Gitlab?

Pretože keď bolo potrebné vytvoriť súkromné úložiská pre domáce projekty, boli zaplatené na GitHub a bol som chamtivý. Repozitáre sa stali voľnými, ale zatiaľ to nie je dostatočný dôvod, aby som prešiel na GitHub.

Prečo nie Azure DevOps Pipelines?

Pretože tam je nastavenie elementárne - nie je potrebná ani znalosť príkazového riadku. Integrácia s externými poskytovateľmi git – v niekoľkých kliknutiach, import kľúčov SSH na odoslanie commitov do úložiska – aj kanál je ľahko nakonfigurovaný, aj keď nie zo šablóny.

Východisková pozícia: čo máte a čo chcete

Máme:

úložisko v GitLab.

Chceme:

automatické zostavovanie a testovanie pre každú žiadosť o zlúčenie,
zostavenie balíkov pre každú žiadosť o zlúčenie a ich odoslanie do hlavného servera za predpokladu, že v správe odovzdania je určitý riadok,
odosielanie vytvorených balíkov do súkromného informačného kanála v Azure DevOps,
zostavenie dokumentácie a publikovanie na stránkach GitLab,
odznaky!11

Opísané požiadavky organicky spadajú do nasledujúceho modelu potrubia:

1. fáza - montáž
- Zhromažďujeme kód, publikujeme výstupné súbory ako artefakty
2. fáza – testovanie
- Získavame artefakty z fázy zostavenia, spúšťame testy, zbierame údaje o pokrytí kódu
Fáza 3 – Odoslať
- Úloha 1 – zostavte nugetový balík a odošlite ho do Azure DevOps
- Úloha 2 – zhromaždíme stránku z xmldoc v zdrojovom kóde a zverejníme ju na stránkach GitLab

Začnime!

Zhromažďovanie konfigurácie

Príprava účtov

Vytvorte si účet v Microsoft Azure
Ísť do Azure DevOps
Vytvárame nový projekt
1. Meno - ľubovoľné
2. Viditeľnosť - ľubovoľná
Po kliknutí na tlačidlo Vytvoriť sa projekt vytvorí a budete presmerovaní na jeho stránku. Na tejto stránke môžete zakázať nepotrebné funkcie tak, že prejdete do nastavení projektu (spodný odkaz v zozname vľavo -> Prehľad -> Blok Azure DevOps Services)
Prejdite na položku Atrifacts a kliknite na položku Vytvoriť informačný kanál
1. Zadajte názov zdroja
2. Vyberte viditeľnosť
3. Zrušte začiarknutie Zahrňte balíčky z bežných verejných zdrojov, aby sa zdroj nezmenil na klon dump nuget
Kliknite na Connect to feed, vyberte Visual Studio, skopírujte Source z bloku Machine Setup
Prejdite do nastavení účtu, vyberte Osobný prístupový token
Vytvorte nový prístupový token
1. Meno - ľubovoľné
2. Organizácia – aktuálna
3. Platnosť maximálne 1 rok
4. Rozsah – balenie/čítanie a zápis
Skopírujte vytvorený token - po zatvorení modálneho okna bude hodnota nedostupná
Prejdite do nastavení úložiska v GitLab, vyberte nastavenia CI / CD
Rozbaľte blok Premenné, pridajte nový
1. Názov - ľubovoľný bez medzier (bude dostupný v príkazovom prostredí)
2. Hodnota - prístupový token z odseku 9
3. Vyberte premennú masky

Tým je predkonfigurácia hotová.

Príprava konfiguračného rámca

V predvolenom nastavení používa konfigurácia CI/CD v GitLab súbor .gitlab-ci.yml z koreňového adresára úložiska. V nastaveniach úložiska si môžete nastaviť ľubovoľnú cestu k tomuto súboru, v tomto prípade to však nie je potrebné.

Ako vidíte z rozšírenia, súbor obsahuje konfiguráciu vo formáte YAML. Dokumentácia podrobne uvádza, ktoré kľúče môžu byť obsiahnuté na najvyššej úrovni konfigurácie a na každej z vnorených úrovní.

Najprv pridajme do konfiguračného súboru odkaz na obrázok dockera, v ktorom sa budú úlohy vykonávať. Na to nájdeme Stránka obrázkov .Net Core na Docker Hub. V GitHub existuje podrobný návod, ktorý obrázok si vybrať pre rôzne úlohy. Obrázok s .Net Core 3.1 je pre nás vhodný na zostavenie, takže kľudne pridajte prvý riadok do konfigurácie

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

Teraz, keď sa kanál spustí z úložiska obrázkov spoločnosti Microsoft, stiahne sa zadaný obrázok, v ktorom sa vykonajú všetky úlohy z konfigurácie.

Ďalším krokom je pridanie stupeň's. V predvolenom nastavení GitLab definuje 5 fáz:

.pre - vykonaná až do všetkých fáz,
.post - vykonávané po všetkých fázach,
build - prvý po .pre javisko,
test - druhá fáza,
deploy - tretia etapa.

Nič vám však nebráni v ich explicitnom vyhlásení. Poradie, v ktorom sú kroky uvedené, ovplyvňuje poradie, v ktorom sa vykonávajú. Pre úplnosť dodajme ku konfigurácii:

stages:
  - build
  - test
  - deploy

Pre ladenie má zmysel získať informácie o prostredí, v ktorom sa úlohy vykonávajú. Pridajme globálnu sadu príkazov, ktoré sa vykonajú pred každou úlohou s before_script:

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

Zostáva pridať aspoň jednu úlohu, aby sa po odoslaní commitov spustil pipeline. Zatiaľ pridáme prázdnu úlohu na demonštráciu:

dummy job:
  script:
    - echo ok

Spustíme validáciu, dostaneme správu, že je všetko v poriadku, potvrdíme, zatlačíme, pozrieme sa na výsledky na stránke ... A dostaneme chybu skriptu - bash: .PSVersion: command not found. wtf?

Všetko je logické – bežci (zodpovední za vykonávanie skriptov úloh a poskytovaní GitLabom) používajú štandardne bash vykonávať príkazy. Môžete to opraviť tak, že v popise úlohy explicitne špecifikujete, aké značky by mal mať spúšťací kanál:

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

Skvelé! Potrubie teraz beží.

Pozorný čitateľ si po zopakovaní uvedených krokov všimne, že úloha bola dokončená vo fáze test, aj keď etapu sme nešpecifikovali. Ako asi tušíte test je predvolený krok.

Pokračujme vo vytváraní kostry konfigurácie pridaním všetkých vyššie popísaných úloh:

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

Získali sme síce nie zvlášť funkčné, ale predsa správne potrubie.

Nastavenie spúšťačov

Vzhľadom na to, že pre žiadnu z úloh nie sú špecifikované žiadne spúšťacie filtre, potrubie bude plne sa vykoná zakaždým, keď sa odovzdanie odošle do úložiska. Keďže toto vo všeobecnosti nie je želané správanie, nastavíme spúšťacie filtre pre úlohy.

Filtre je možné konfigurovať v dvoch formátoch: iba/okrem и Pravidlá. v skratke, only/except umožňuje konfigurovať filtre podľa spúšťačov (merge_request, napríklad - nastaví úlohu, ktorá sa má vykonať vždy, keď je vytvorená požiadavka na stiahnutie a zakaždým, keď sú odovzdané príkazy odoslané do vetvy, ktorá je zdrojom v žiadosti o zlúčenie) a názvy vetiev (vrátane použitia regulárnych výrazov); rules umožňuje prispôsobiť súbor podmienok a voliteľne zmeniť podmienku vykonania úlohy v závislosti od úspechu predchádzajúcich úloh (when v GitLab CI/CD).

Pripomeňme si súbor požiadaviek – zostavenie a testovanie iba pre žiadosť o zlúčenie, balenie a odoslanie do Azure DevOps – pre žiadosť o zlúčenie a odoslanie do hlavného servera, generovanie dokumentácie – pre odoslanie do hlavného servera.

Najprv nastavme úlohu zostavenia kódu pridaním pravidla, ktoré sa spustí iba pri žiadosti o zlúčenie:

build job:
  # snip
  only:
    - merge_request

Teraz nastavme úlohu balenia tak, aby sa spustila pri žiadosti o zlúčenie a pridali odovzdania do hlavného servera:

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

Ako vidíte, všetko je jednoduché a priamočiare.

Úlohu môžete tiež nastaviť tak, aby sa spustila iba vtedy, ak je vytvorená žiadosť o zlúčenie s konkrétnou cieľovou alebo zdrojovou vetvou:

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

Za podmienok môžete použiť tu uvedené premenné; pravidlá rules nezlučiteľné s pravidlami only/except.

Konfigurácia ukladania artefaktov

Počas úlohy build job budeme mať vytvorené artefakty, ktoré sa dajú znova použiť v nasledujúcich úlohách. Ak to chcete urobiť, musíte do kľúča pridať cesty ku konfigurácii úlohy, súbory, ktoré budete musieť uložiť a znova použiť v nasledujúcich úlohách artifacts:

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

Cesty podporujú zástupné znaky, čo určite uľahčuje ich nastavenie.

Ak úloha vytvorí artefakty, potom k nim bude mať prístup každá nasledujúca úloha – budú sa nachádzať pozdĺž rovnakých ciest ku koreňu úložiska, ktoré boli zhromaždené z pôvodnej úlohy. Artefakty sú tiež k dispozícii na stiahnutie na stránke.

Teraz, keď máme konfiguračný rámec pripravený (a otestovaný), môžeme pristúpiť k samotnému písaniu skriptov pre úlohy.

Píšeme scenáre

Možno, kedysi dávno, v ďalekej galaxii, bolo vytváranie projektov (vrátane tých na .net) z príkazového riadku utrpením. Teraz môžete projekt zostavovať, testovať a publikovať v 3 tímoch:

dotnet build
dotnet test
dotnet pack

Prirodzene, existujú určité nuansy, kvôli ktorým si príkazy trochu skomplikujeme.

Chceme zostavu vydania, nie zostavu ladenia, takže ku každému príkazu pridávame -c Release
Pri testovaní chceme zbierať údaje o pokrytí kódu, preto musíme do testovacích knižníc zahrnúť analyzátor pokrytia:
1. Pridajte balík do všetkých testovacích knižníc coverlet.msbuild: dotnet add package coverlet.msbuild z priečinka projektu
2. Pridajte do príkazu na testovanie /p:CollectCoverage=true
3. Pridajte kľúč do konfigurácie testovacej úlohy, aby ste získali výsledky pokrytia (pozri nižšie)
Pri balení kódu do balíčkov nuget nastavte výstupný adresár pre balíčky: -o .

Zhromažďovanie údajov o pokrytí kódom

Po spustení testov Coverlet vytlačí štatistiku behu do konzoly:

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 vám umožňuje zadať regulárny výraz na získanie štatistík, ktoré potom možno získať vo forme odznaku. Regulárny výraz sa špecifikuje v nastaveniach úlohy pomocou kľúča coverage; výraz musí obsahovať zachytávaciu skupinu, ktorej hodnota bude odovzdaná odznaku:

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

Tu získame štatistiky z linky s celkovým pokrytím linky.

Publikovanie balíkov a dokumentácie

Obe akcie sú naplánované na poslednú fázu ropovodu – keďže montáž a testy prešli, môžeme sa o náš vývoj podeliť so svetom.

Najprv zvážte publikovanie do zdroja balíka:

Ak projekt nemá konfiguračný súbor nuget (nuget.config), vytvorte nový: dotnet new nugetconfig
Prečo: obrázok nemusí mať prístup k zápisu do globálnych (používateľov a strojových) konfigurácií. Aby sme nezachytili chyby, jednoducho vytvoríme novú lokálnu konfiguráciu a pracujeme s ňou.
Pridajme nový zdroj balíka do lokálnej konfigurácie: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - názov lokálneho zdroja, nie je kritický
2. url - URL zdroja z fázy „Príprava účtov“, s. 6
3. organization - názov organizácie v Azure DevOps
4. gitlab variable - názov premennej s prístupovým tokenom pridaný do GitLabu („Príprava účtov“, s. 11). Prirodzene, vo formáte $variableName
5. -StorePasswordInClearText - hack na obídenie chyby odmietnutia prístupu (Nie som prvý, kto stúpil na tieto hrable)
6. V prípade chýb môže byť užitočné doplniť -verbosity detailed
Odoslanie balíka zdroju: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Všetky balíky posielame z aktuálneho adresára, tzn *.nupkg.
2. name - z vyššie uvedeného kroku.
3. key - ľubovoľný riadok. V Azure DevOps v okne Pripojiť k informačnému kanálu je príkladom vždy riadok az.
4. -skipduplicate - pri pokuse o odoslanie už existujúceho balíka bez tohto kľúča zdroj vráti chybu 409 Conflict; s kľúčom sa odoslanie preskočí.

Teraz nastavíme vytváranie dokumentácie:

Najprv v úložisku, v hlavnej vetve, inicializujeme projekt docfx. Ak to chcete urobiť, spustite príkaz z koreňa docfx init a interaktívne nastaviť kľúčové parametre pre stavebnú dokumentáciu. Podrobný popis minimálneho nastavenia projektu tu.
1. Pri konfigurácii je dôležité špecifikovať výstupný adresár ..public - GitLab v predvolenom nastavení berie obsah verejného priečinka v koreňovom adresári úložiska ako zdroj pre Pages. Pretože projekt sa bude nachádzať v priečinku vnoreného do úložiska - pridajte výstup o úroveň vyššie v ceste.
Prenesme zmeny do GitLabu.
Pridajte úlohu do konfigurácie potrubia pages (vyhradené slovo pre úlohy publikovania stránok na stránkach GitLab):
1. skript:
  1. nuget install docfx.console -version 2.51.0 - nainštalovať docfx; verzia je špecifikovaná, aby sa zabezpečilo, že inštalačné cesty balíka sú správne.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - zhromažďovanie dokumentácie
2. Artefakty uzlov:

pages:
  # snip
  artifacts:
    paths:
      - public

Lyrická odbočka o docfx

Predtým som pri nastavovaní projektu špecifikoval zdroj kódu pre dokumentáciu ako súbor riešenia. Hlavnou nevýhodou je, že dokumentácia sa vytvára aj k testovacím projektom. V prípade, že to nie je potrebné, môžete túto hodnotu nastaviť na uzol metadata.src:

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

metadata.src.src: "../" - ideme o úroveň vyššie vzhľadom na miesto docfx.json, pretože vo vzoroch vyhľadávanie v strome adresárov nefunguje.
metadata.src.files: ["**/*.csproj"] - globálny vzor, zhromažďujeme všetky projekty C # zo všetkých adresárov.
metadata.src.exclude: ["*.tests*/**"] - globálny vzor, vylúčiť všetko z priečinkov s .tests V názve

Medzisúčet

Takáto jednoduchá konfigurácia môže byť vytvorená len za pol hodiny a pár šálok kávy, čo vám umožní skontrolovať, či je kód zostavený a testy prejdú, zostaviť nový balík, aktualizovať dokumentáciu a potešiť oko krásnym odznaky v súbore README projektu pri každej žiadosti o zlúčenie a odoslaní hlavnému serveru.

Konečný .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

Keď už hovoríme o odznakoch

Kvôli nim sa predsa všetko začalo!

Odznaky so stavmi kanálov a pokrytím kódu sú dostupné v GitLab v nastaveniach CI/CD v bloku kanálov Gtntral:

Vytvoril som odznak s odkazom na dokumentáciu na platforme shields.io - všetko je tam celkom jednoduché, môžete si vytvoriť svoj vlastný odznak a získať ho pomocou žiadosti.

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

Azure DevOps Artifacts vám tiež umožňuje vytvárať odznaky pre balíčky s najnovšou verziou. Ak to chcete urobiť, v zdroji na lokalite Azure DevOps musíte kliknúť na Vytvoriť odznak pre vybratý balík a skopírovať značku zníženia:

Pridanie krásy

Zvýraznenie bežných fragmentov konfigurácie

Pri písaní konfigurácie a prehľadávaní dokumentácie som narazil na zaujímavú vlastnosť YAML – opätovné použitie fragmentov.

Ako môžete vidieť v nastaveniach úlohy, všetky vyžadujú značku windows na bežec a sú spustené, keď je odoslaná požiadavka na zlúčenie na hlavný/vytvorený (okrem dokumentácie). Pridajme to k fragmentu, ktorý znova použijeme:

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

A teraz môžeme vložiť fragment deklarovaný skôr v popise úlohy:

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

Názvy fragmentov musia začínať bodkou, aby neboli interpretované ako úloha.

Verzia balíkov

Pri vytváraní balíka kompilátor kontroluje prepínače príkazového riadku av prípade ich neprítomnosti súbory projektu; keď nájde uzol Version, vezme jeho hodnotu ako verziu zostavovaného balíka. Ukázalo sa, že ak chcete vytvoriť balík s novou verziou, musíte ho buď aktualizovať v súbore projektu, alebo ho odovzdať ako argument príkazového riadku.

Pridajme ešte jeden Wishlist - nech sú vedľajšie dve čísla vo verzii rok a dátum zostavenia balíka a pridajte predbežné verzie. Tieto údaje môžete samozrejme pridať do súboru projektu a skontrolovať ich pred každým odoslaním – ale môžete to urobiť aj v potrubí, zhromaždením verzie balíka z kontextu a jej odovzdaním cez argument príkazového riadka.

Dohodnime sa, že ak správa odovzdania obsahuje riadok ako release (v./ver./version) <version number> (rev./revision <revision>)?, potom zoberieme verziu balíka z tohto riadku, doplníme ju o aktuálny dátum a odošleme ju ako argument príkazu dotnet pack. Pri absencii riadku balík jednoducho nevyzdvihneme.

Tento problém rieši nasledujúci 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

Pridanie skriptu k úlohe pack and deploy job a prísne dodržiavať zostavovanie balíkov v prítomnosti daného reťazca v správe odovzdania.

Celkom

Po asi polhodine alebo hodine písania konfigurácie, ladení v lokálnom powershell a možno aj niekoľkých neúspešných spustení sme dostali jednoduchú konfiguráciu na automatizáciu rutinných úloh.

Samozrejme, GitLab CI / CD je oveľa rozsiahlejší a mnohostrannejší, ako by sa mohlo zdať po prečítaní tejto príručky - to vobec nie je pravda. Dokonca aj tam Auto DevOps jedovoľovať

automaticky zisťovať, zostavovať, testovať, nasadzovať a monitorovať vaše aplikácie

Teraz je v pláne nakonfigurovať kanál na nasadenie aplikácií do Azure pomocou Pulumi a automaticky určiť cieľové prostredie, čomu sa budeme venovať v nasledujúcom článku.

Zdroj: hab.com