🥇CI/CD útmutató a GitLabhoz (szinte) teljesen kezdőknek

Vagy hogyan szerezhetek szép jelvényeket a projektemhez egy este gondtalan kódolás mellett

Valószínűleg minden fejlesztőnél, akinek legalább egy pet-projektje van, egy idő után felmerül a vágy a szép jelvények iránt, amelyek státuszokat, kódlefedettséget, csomagverziókat mutatnak a NuGet-en… Engem ez a vágy indított arra, hogy megírjam ezt a cikket. Az írás előkészítése során ilyen szépségekkel gazdagodtam az egyik projektomban:

A cikkben egy .NET Core-os osztálykönyvtár folyamatos integrációjának és szállításának alapbeállításait fogjuk áttekinteni a GitLab-ban, a dokumentáció GitLab Pages-re való kiadásával és az összeállított csomagok elküldésével egy privát feed-be az Azure DevOps-ban.

A fejlesztési környezet a VS Code volt kiegészítővel GitLab Workflow az előírások fájljának validálására közvetlenül a fejlesztési környezetből.

Rövid bevezetés

A CD az, amikor éppen most toltad fel a kódot, és a kliens máris összeomlott?

Mi a CI/CD és miért szükséges — ezt könnyen ki lehet guglizni. A GitLab pipelinek beállításáról részletes dokumentációt találni szintén nem nehéz. Itt röviden és lehetőség szerint hibák nélkül leírom a rendszer működését madártávlatból:

a fejlesztő eljuttatja a commitot a tárolóhoz, merge requestet hoz létre a weboldalon, vagy bármilyen más módon egyértelműen vagy nem egyértelműen elindítja a pipelint,
a konfigurációból kiválasztják az összes olyan feladatot, amelynek feltételei lehetővé teszik az elindulását adott kontextusban,
a feladatok a lépéseik szerint szerveződnek,
a lépések egymás után hajtódnak végre — azaz. párhuzamosan az adott lépés összes feladata végrehajtásra kerül,
ha a lépés nem sikerül (azaz ha a lépésnél legalább egy feladat nem teljesül) — a pipeline leáll (majdnem mindig),
ha az összes lépés sikeresen zárul, a pipeline sikeresen teljesültnek számít.

Így tehát rendelkezésünkre áll:

a pipeline — a lépésekbe szervezett feladatok halmaza, amelyben kódot lehet összeállítani, tesztelni, csomagolni, a kész összesítést a felhőszolgáltatásra telepíteni, és így tovább,
lépés (stage) — a pipeline szervezésének egysége, amely 1+ feladatot tartalmaz,
feladat (job) — a pipeline munkavégzésének egysége. Egy szkriptből (kötelező) áll, a végrehajtás feltételeiből, a publikálás/artefaktumok cache-elési beállításaiból és sok egyéb dologból.

Tehát a CI/CD beállításának feladata az, hogy létrehozzunk egy feladatkészletet, amely megvalósítja az összes szükséges műveletet a kód és a műtárgyak összeállításához, teszteléséhez és közzétételéhez.

Kezdés előtt: miért?

Miért a GitLab?

Mert amikor szükség volt privát repók létrehozására a pet-projektekhez, a GitHub-on ezek fizetősek voltak, én pedig - spórolós. A repók ingyenessé váltak, de ez még nem elég ok számomra a GitHub-ra való áttéréshez.

Miért nem az Azure DevOps Pipelines?

Mert ott a beállítás egyszerű — még parancssori tudás sem szükséges. Az integráció a külső git szolgáltatókkal pár kattintással megoldható, az SSH kulcsok importálása a repóba történő commithoz szintén, a pipeline könnyen beállítható akár sablon nélkül is.

Kiindulási helyzet: mi van és mi kellene

Van:

repo a GitLab-on.

Amit szeretnénk:

automatikus összeállítás és tesztelés minden merge request számára,
csomagok összeállítása minden merge request és master ágba való push esetén, ha a commit üzenetében van egy adott sor,
a létrehozott csomagok elküldése egy privát feedbe az Azure DevOps-ban,
dokumentáció készítése és közzététele a GitLab Pages-en,
jelvények!11

A fent leírt követelmények szervesen illeszkednek a következő pipeline modellbe:

1. lépés — építés
- A kód összeállítása, a kimeneti fájlok közzététele mint műtárgyak
2. lépés — tesztelés
- Az összeállítás során létrehozott műtárgyak megszerzése, tesztek futtatása, kódlefedettségi adatok összeállítása
3. lépés — küldés
- 1. feladat — nuget csomag összeállítása és elküldése az Azure DevOps-ba
- 2. feladat — weboldal összeállítása az xmldoc-ból a forráskódban és közzététele a GitLab Pages-en

Kezdjük!

Konfiguráció összeállítása

Fiókok előkészítése

Fiók létrehozása itt Microsoft Azure
Lépjünk a következőre Azure DevOps
Új projekt létrehozása
1. Név — tetszőleges
2. Láthatóság — bármilyen
A Create gombra kattintva a projekt létrejön, és átkerülünk a projekt oldalára. Ezen az oldalon kikapcsolhatjuk a felesleges lehetőségeket a projekt beállításaiban (alsó link az oldalsávban -> Overview -> Azure DevOps Services blokk)
Átmegyünk az Atrifacts-ra, kattintunk a Create feed gombra
1. Megadjuk a forrás nevét
2. Válasszuk a láthatóságot
3. Töröljük a pipát Common public sources csomagok belefoglalása, hogy a forrás ne váljon a nuget klónok szemétlerakójává
Kattintunk a Connect to feed gombra, választjuk a Visual Studio-t, a Machine Setup blokkban másoljuk a Source-t
Elmegyünk a fiók beállításaihoz, válasszuk a Personal Access Token-t
Új hozzáférési token létrehozása
1. Név — tetszőleges
2. Szervezet — a jelenlegi
3. Érvényességi idő — maximum 1 év
4. A hatókör (scope) — Csomagolás / Írás & Olvasás
A létrehozott token másolása — a modális ablak bezárása után az érték már nem lesz elérhető
Belépünk a GitLab tároló beállításaiba, kiválasztjuk a CI / CD beállításokat
Kibővítjük a Változók szakaszt, hozzáadunk egy újat
1. Név — bármilyen, szóközök nélkül (elérhető lesz a parancsértelmezőben)
2. Érték — a hozzáférési token a 9. pontból
3. Válasszuk a Maszk változó lehetőséget

Ezen a ponton a beállítások előkészítése befejeződött.

Előkészítjük a konfiguráció vázát

Alapértelmezetten a CI / CD beállításhoz a GitLab a fájlt használja .gitlab-ci.yml a tároló gyökéréből. Beállíthatjuk a fájl tetszőleges elérési útját a tároló beállításaiban, de ebben az esetben ez nem szükséges.

Ahogy a kiterjesztésből látható, a fájl konfigurációt tartalmaz YAML. A dokumentációban részletesen le van írva, milyen kulcsok lehetnek a konfiguráció felső szintjén és minden beágyazott szinten.

Először adjunk hozzá a konfigurációs fájlhoz egy linket a docker-képre, amelyen a feladatok végrehajtása történik. Ehhez keressük meg a .Net Core képek oldalát a Docker Hub-on. A GitHub ott részletes útmutatás található arról, hogy milyen képet válasszunk különböző feladatokhoz. A buildeléshez nekünk megfelelő lesz a .Net Core 3.1 kép, ezért merészén hozzáadjuk az első sorban a konfigurációhoz

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

Most, amikor elindítjuk a pipeline-t a Microsoft képtárházából, a megadott kép le lesz töltve, amelyben az összes feladat végrehajtásra kerül a konfiguráció szerint.

A következő lépés — hozzáadni stagestádiumokat. Alapértelmezés szerint a GitLab öt stádiumot határoz meg:

.pre — minden stádium előtt végrehajtódik,
.post — minden stádium után végrehajtódik,
build — első a .pre stádium után,
teszt — második stádium,
after_deploy — harmadik stádium.

Semmi sem akadályozza meg, hogy ezeket explicit módon bejelentsük. A stádiumok megadott sorrendje befolyásolja a végrehajtás sorrendjét. A teljesség kedvéért hozzáadjuk a konfigurációhoz:

stages:
  - build
  - test
  - deploy

Hibakeresés céljából érdemes információt kapni arról a környezetről, amelyben a feladatok végrehajtásra kerülnek. Adjuk hozzá a globális parancsok készletét, amely minden feladat előtt végrehajtásra kerül, a before_cache:

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

Már csak annyit kell hozzáadnunk, hogy legalább egy feladatot megvalósítsunk, hogy amikor commitokat küldünk, a pipeline elinduljon. Egyelőre hozzáadunk egy üres feladatot a demonstrációhoz:

dummy job:
  script:
    - echo ok

Elindítjuk a validálást, megkapjuk az üzenetet, hogy minden rendben van, commitálunk, push-olunk, megnézzük az eredményeket a weboldalon... és hibaüzenetet kapunk a skripttől — bash: .PSVersion: parancs nem található. WTF?

Minden logikus – alapértelmezés szerint a runner-ek (amelyek a feladatok szkriptjeinek végrehajtásáért felelősek, és amelyeket a GitLab biztosít) használják bash a parancsok végrehajtásához. Ezt a dolgot javíthatjuk úgy, hogy egyértelműen megadjuk a feladat leírásában, mely címkéknek kell lennie a végrehajtó pipeline runnernek:

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

Remek! Most a pipeline végrehajtásra került.

A figyelmes olvasó, aki megismétli a felsorolt lépéseket, észre fogja venni, hogy a feladat a tesztstádiumban hajtódott végre, pedig nem adtuk meg a stádiumot. Ahogy sejthető, teszt ez az alapértelmezett stádium.

Folytassuk a konfigurációs vázlat létrehozását, hozzáadva az összes, a fenti leírásban szereplő feladatot:

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

Kaptunk egy nem túl funkcionális, de mindenesetre helyes pipeline-t.

Trigger beállítások

Mivel egyetlen feladathoz sem adtunk meg aktiválási szűrőket, a pipeline teljesen minden egyes commit repo-ba való elküldésekor végrehajtásra kerül. Mivel ez általában nem kívánt viselkedés, beállítjuk a feladatok aktiválási szűrőit.

A szűrők két formátumban állíthatók be: only/except és szabályok. Röviden, only/except lehetővé teszi a trigger szűrők beállítását (merge_request, például beállítja a feladatot, hogy minden egyes merge request létrehozásakor és minden egyes commit küldésekor, amely a merge request forrása, végrehajtásra kerüljön) és a branch nevek (beleértve a reguláris kifejezések használatát); szabályok lehetővé teszi feltételsorozatok beállítását és opcionálisan a feladat végrehajtásának módosítását a korábbi feladatok sikerétől függően (when a GitLab CI/CD-ben).

Emlékezzünk a követelmények sorozatára – kód buildelés és tesztelés csak merge request esetén, csomagolás és küldés az Azure DevOps-ba – merge request és master push esetén, dokumentáció generálás – master push esetén.

Kezdjük a kód buildelésével, hozzáadva egy aktiválási szabályt, amely csak merge request esetén érvényes:

build job:
  # snip
  only:
    - merge_request

Most állítsuk be a csomagolási feladatot, hogy aktiválódjon merge request és a masterbe való commit esetén:

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

Mint látható, minden egyszerű és egyenes.

A feladatot be lehet állítani, hogy csak akkor aktiválódjon, ha egy meghatározott cél- vagy kiindulási ággal rendelkező merge request jön létre:

  szabályok:
    - ha: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

A feltételekben használhatók a felsorolt változók; szabályok szabályok nem kompatibilisek a szabályokkal only/except.

Artifaktumok mentési beállítása

A feladat végrehajtása során build feladat artifaktumok jönnek létre, amelyek újrahasználhatók a későbbi feladatokban. Ehhez a feladat konfigurációjába hozzá kell adni azokat az útvonalakat, fájlokat, amelyeket meg kell menteni és újrahasználni a következő feladatokban, a kulcsban artifaktumok:

build feladat:
  # snip
  artifaktumok:
    útvonalak:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

Az útvonalak támogatják a wildcards-t, ami bizonyosan megkönnyíti a megadásukat.

Ha a feladat artifaktumokat generál, akkor minden következő feladat hozzáférhet ezekhez — ezek ugyanazon az úton lesznek elérhetők a repozitórium gyökeréhez képest, ahonnan az eredeti feladatból származnak. Az artifaktumok az oldalon is letölthetők.

Most, hogy a konfiguráció vázlata készen van (és ellenőrizve is lett), áttérhetünk a feladatok szkripteinek megírására.

Szkriptek írása

Lehetséges, hogy valamikor régen, egy messzi-messzi galaxisban, a projekteket (többek között a .net-et is) a parancssorból összegyűjteni fájdalmas volt. Most azonban három parancssal összeállítható, tesztelhető és publikálható egy projekt:

dotnet build
dotnet test
dotnet pack

Természetesen vannak bizonyos részletek, amelyek miatt kissé bonyolítjuk a parancsokat.

Kiadásit, nem hibakeresőt szeretnénk, ezért minden parancs végéhez hozzáadunk -c Release
A tesztelés során a kódlefedettségi adatokat szeretnénk gyűjteni, ezért szükséges a tesztkönyvtárakban a lefedettség-analizáló csatlakoztatása:
1. Minden tesztkönyvtárhoz hozzá kell adni a csomagot coverlet.msbuild: dotnet add package coverlet.msbuild a projekt mappából
2. A tesztelési parancshoz hozzáadjuk /p:CollectCoverage=true
3. A tesztelési feladat konfigurációjába hozzáadunk egy kulcsot az eredmények megszerzéséhez (lásd alább)
A kód nuget-csomagba csomagolásakor megadjuk a kimeneti könyvtárat a csomagok számára: -o .

Kódlefedettségi adatok összegyűjtése

A Coverlet a tesztek futtatása után statisztikát jelenít meg a futtatásról a konzolon:

A lefedettség kiszámítása...
  Jelentés generálása: 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Modul       | Sor    | Ág     | Módszer |
+-------------+--------+--------+--------+
| projekt 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| projekt 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| projekt 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Sor    | Ág     | Módszer |
+---------+--------+--------+--------+
| Összesen | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Átlag   | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

A GitLab lehetővé teszi, hogy reguláris kifejezést adjunk meg a statisztikákhoz, amelyeket később badge-ként nyerhetünk ki. A reguláris kifejezést a feladat beállításaiban kell megadni a kulccsal coverage; a kifejezésben egy capture-csoportnak kell szerepelnie, amelynek az értéke kerül átadásra a badge-be:

teszt és lefedettségi feladat:
  # rövidítve
  lefedettség: \/|s*Összesen*|s*(d+[,.]d+%)\/

Itt a vonalak szerinti összlefedettség statisztikáját kapjuk egy sorból.

Csomagok és dokumentáció közzététele

Mindkét műveletet az utolsó lépésre ütemeztük — mivel a build és a tesztek sikeresen lezajlottak, megoszthatjuk a világ előtt az elkészült munkánkat.

Először nézzük meg a csomagforrás közzétételét:

Ha a projektben nincs nuget konfigurációs fájl (nuget.config), készítsünk egy újat: dotnet new nugetconfig
Miért: a képen lehet, hogy tiltanak a globális (felhasználói és gépi) konfigurációkhoz való írási hozzáférést. Hogy elkerüljük a hibákat, egyszerűen létrehozunk egy új helyi konfigurációt, és azzal dolgozunk.
Adjuk hozzá az új csomagforrást a helyi konfigurációhoz: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name — a helyi forrás neve, nem lényeges
2. url — a forrás URL-je a "Fiókok előkészítése" lépés 6-ból
3. szervezet — a szervezet neve az Azure DevOps-ban
4. gitlab változó — a GitLab-ba hozzáadott hozzáférési token nevét tartalmazó változó ("Fiókok előkészítése", lépés 11). Természetesen a következő formátumban: $variableName
5. -StorePasswordInClearText — hack a hozzáférési hiba megkerülésére (nem vagyok az első, aki erre a hibára lépett rá)
6. Hibák esetén hasznos lehet hozzáadni -verbosity detailed
Csomag küldése a forráshoz: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Az aktuális könyvtár összes csomagját küldjük, ezért *.nupkg.
2. name — a korábban megadott lépésből.
3. key — bármilyen szöveg. Az Azure DevOps-ban a ‘Connect to feed’ ablakban mindig egy példaként adják meg a szöveget az.
4. -skipduplicate — amikor megpróbálunk egy már létező csomagot küldeni, anélkül, hogy ez a kulcs ott lenne, a forrás hibát ad vissza. 409 Konfliktus; a kulccsal a küldés elmarad.

Most beállítjuk a dokumentáció létrehozását:

Először is, a repository-ben, a master ágon inicializáljuk a docfx projektet. Ehhez a gyökérből kell futtatni a parancsot docfx init és interaktív módban megadjuk a dokumentáció építéséhez szükséges kulcsparamétereket. Részletes leírás a minimális projektbeállításról itt.
1. Beállításkor fontos megadni a kimeneti könyvtárat ..public — A GitLab alapértelmezés szerint a repository gyökerében található public mappa tartalmát veszi alapul a Pages forráshoz. Mivel a projekt a repository-n belüli mappában lesz, egy szinttel feljebb kell mennünk az útvonalban.
Küldjük el a módosításokat a GitLab-ra.
A pipeline konfigurációjához hozzáadunk egy feladatot pages (fenntartott szó a weboldalak GitLab Pages-ben történő publikálására vonatkozó feladatokhoz):
1. Script:
  1. nuget install docfx.console -version 2.51.0 — telepíti a docfx-et; a verziót azért adjuk meg, hogy biztosítsuk a csomagtelepítési utak helyességét.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json — összeállítjuk a dokumentációt
2. Artifacts csomópont:

pages:
  # snip
  artifacts:
    paths:
      - public

Lírai kitérő a docfx-ről

Korábban a projekt beállításakor a dokumentáció forrását a megoldásfájlra adtam meg. Fő hátrány — a dokumentáció a tesztprojektekhez is készült. Ha ez nem szükséges, akkor beállíthatjuk a következő értéket a csomóponthoz metadata.src:

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

metadata.src.src: "..\" — egy szinttel feljebb lépünk a pozícióhoz képest docfx.json, mivel a mintázatokban nem működik a felfelé keresés a könyvtárfán.
metadata.src.files: ["**/*.csproj"] — globális minta, összegyűjtjük az összes C# projektet az összes könyvtárból.
metadata.src.exclude: ["*.tests*/**"] — globális minta, kizárunk mindent a mappákból, amelyek .tests a nevében van

Közbenső következtetés

Egy ilyen egyszerű konfigurációt mindössze fél óra és pár csésze kávé alatt össze lehet állítani, amely lehetővé teszi, hogy minden egyes merge kérés és mesterbe küldés során ellenőrizzük, hogy a kód összeáll-e és a tesztek átmennek, új csomagot állítunk össze, frissítjük a dokumentációt, és örömet okozunk szép badge-ekkel a projekt README-jében.

Végső .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+%)\n  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

Épp a jelvényekről

Ezek miatt indult minden!

A pipeline státuszok és kódlefedettségi jelvényei a GitLabban elérhetők a CI/CD beállításoknál a Gtntral pipelines blokkban:

A dokumentációra mutató jelvényt a Shields.io platformon készítettem — ott minden eléggé egyértelmű, létrehozhatod a saját jelvényedet és lekérdezéssel megkaphatod azt.

![Példa a Shields.io-ról](https://img.shields.io/badge/custom-badge-blue)

Az Azure DevOps Artifacts szintén lehetővé teszi a csomagokhoz jelvények létrehozását a aktuális verzió megadásával. Ehhez az Azure DevOps webhelyén a forrásnál kattints a Készíts jelvényt a kiválasztott csomaghoz, és másold ki a markdown szintaxist:

Tegyük szebbé

Kiemeljük a közös konfigurációs fragmentumokat

A konfiguráció írása és a dokumentációban való keresgélés során felfedeztem egy érdekes YAML lehetőséget — a fragmentumok újrahasználatát.

Amint az a feladatbeállításokból látható, mindegyik megköveteli, hogy a windows a runner címkéje legyen, és a masterben való beküldéskor / összevonási kérés létrehozásakor lépnek életbe (kivéve a dokumentációt). Ezt adjuk hozzá a fragmentumhoz, amelyet újrahasználunk:

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

Most pedig a feladat leírásában beilleszthetjük a korábban deklarált fragmentumot:

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

A fragmentumok neveinek ponttal kell kezdődniük, hogy ne legyenek feladatként értelmezve.

Csomagok verzió kezelése

Amikor egy csomagot hozunk létre, a fordító ellenőrzi a parancssori kulcsokat, és ha azok nincsenek, a projektfájlokat; megtalálva a Version csomópontot, annak értékét veszi a létrehozott csomag verziójának. Tehát ahhoz, hogy egy új verziójú csomagot állítsunk össze, frissíteni kell a projektfájlban, vagy át kell adni parancssori argumentumként.

Adjunk hozzá még egy kívánságot — a verzió legkisebb két számának legyen az éve és a csomag verziójának dátuma, és adjunk hozzá előzetes verziókat. Természetesen ezeket az adatokat a projektfájlba is hozzáadhatjuk, és ellenőrizhetjük minden beküldés előtt — de ezt megtehetjük a pipeline-ban is, a csomag verziójának összegyűjtésével a kontextusból és átadva parancssori argumentumként.

Feltehetjük, hogy ha a commit üzenetben található egy sor, amely így néz ki: release (v. /ver. /version) <version number> (rev. /revision <revision>)?, akkor ebből a sorból elvesszük a csomag verzióját, hozzáadjuk a jelenlegi dátumot, és átadjuk a következő parancsnak: dotnet pack. Ha a sor hiányzik — egyszerűen nem készítünk csomagot.

Ezt a feladatot a következő szkript oldja meg:

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

Adjuk hozzá a szkriptet a feladathoz: pack and deploy job és figyeljük a csomagok összeállítását, szigorúan a commit üzenetben megadott sor hiányában.

Összesen

Körülbelül fél-egy óra időt eltöltve a konfiguráció megírásával, helyi powershell-ben való hibakereséssel, és talán néhány sikertelen futtatással, egy egyszerű konfigurációt kaptunk a rutinszerű feladatok automatizálásához.

Természetesen a GitLab CI/CD sokkal szélesebb és összetettebb, mint amilyennek a vezetés elolvasása után tűnik — ez egyáltalán nem így van. Még a Auto DevOps is van, amely lehetővé teszi

automatikusan érzékeli, építi, teszteli, telepíti és figyeli az alkalmazásaidat.

Most a tervek között szerepel egy pipeline konfigurálása az alkalmazások Azure-ba való telepítésére, Pulumi használatával, és a célkörnyezet automatikus meghatározásával, amit a következő cikkben fogunk bemutatni.

Forrás: habr.com