Udhëzues për CI/CD në GitLab për (pothuajse) fillestarët e absolutë

Apo si të fitoni disa badge të bukura për projektin tuaj në një mbrëmje të lehtë kodimi

Sigurisht, çdo zhvillues me të paktën një projekt pet kalon në një moment dëshirën për badge të bukura me statuset, mbulimin e kodit, versionet e paketave në nuget… Dhe kjo dëshirë më çoi në shkrimin e këtij artikulli. Gjatë përgatitjes për shkrimin e tij, kam fituar këtë bukuri në një nga projektet e mia:

Artikulli do të shqyrtojë konfigurimin bazik të integrimit dhe dorëzimit të vazhdueshëm për një bibliotekë klasash në .Net Core në GitLab, me publikimin e dokumentacionit në GitLab Pages dhe dërgimin e paketave të ndërtuara në një feed privat në Azure DevOps.

Si mjedis zhvillimi, u përdor VS Code me shtesën GitLab Workflow (për validimin e skedarit të konfigurimit direkt nga mjedisi i zhvillimit).

Hyrje e shkurtër

CD — është kur sapo e pashë kodin dhe klienti ka rënë?

Çfarë është CI/CD dhe përse është e nevojshme — mund të gjendet lehtësisht në Google. Dokumentacioni i plotë për konfigurimin e pipeline-ve në GitLab gjithashtu nuk është e vështirë për t'u gjetur . Këtu do ta përshkruaj shkurtimisht dhe sa më saktë procesin e punës së sistemit nga lart:zhvilluesi dërgon një commit në depo, krijon një kërkesë bashkimi përmes faqes,

• ose ndonjë mënyrë tjetër fillon qartë ose në mënyrë të paaftë pipeline-in nga konfigurimi përzgjidhen të gjitha detyrat, kushtet e së cilave lejojnë që ato të fillohen në këtë kontekst,,
• detyrat organizohen sipas fazave të tyre,
• fazat përkatësisht realizohen — dmth.
• përparësisht kryhen të gjitha detyrat e kësaj faze, nëse faza dështonte (dmth. shkon keq të paktën një nga detyrat e fazës) — pipeline-i ndalet (
• gati gjithmonënëse të gjitha fazat përfundojnë me sukses, pipeline-i konsiderohet se kaloi me sukses.),
• Kështu, kemi:

pipeline — një grup detyrash, të organizuara në faza, në të cilin mund të ndërtosh, testosh, paketosh kodin, shpërndash një ndërtim të gatshëm në një shërbim në cloud, etj.

• fase (
• stage) — një njësi organizimi e pipeline-it, përmban 1+ detyrë,detyrë (
• job) — një njësi pune në pipeline. Konsiston nga një skenar (të paktën), kushtet e ekzekutimit, cilësimet e publikimit/keshit të artefakteve dhe shumë të tjera.) — njësia e punës në pipeline. Konsiston në skript (të domosdoshëm), kushtet e nisjes, cilësimet e publikimit/keqiengjitjes së artefakteve dhe shumë të tjera.

Prandaj, detyra gjatë konfigurimit të CI/CD është të krijojë një grup detyrash që realizojnë gjithë veprimet e nevojshme për ndërtimin, testimin dhe publikimin e kodit dhe artefakteve.

Para fillimit: pse?

• Pse GitLab?

Sepse kur u shfaq nevoja për të krijuar depo private për projektet e mia, në GitHub ato ishin me pagesë, dhe unë isha i kursyer. Depo tani janë falas, por kjo ende nuk është një arsye e mjaftueshme për të kaluar në GitHub.

• Pse jo Azure DevOps Pipelines?

Sepse konfigurimi atje është elementar — nuk kërkohen asnjë njohuri të komandës. Integrimi me ofruesit e jashtëm git — me disa klikime, importimi i çelësave SSH për dërgimin e komiteteve në depo — gjithashtu, pipeline është lehtësisht i konfigurueshëm edhe jashtë një shablloni.

Pozita fillestare: çfarë kemi dhe çfarë duam

Kemi:

• depo në GitLab.

Duam:

• ndërtimin dhe testimin automatik për çdo merge request,
• ndërtimin e paketave për çdo merge request dhe dërgimin në master në kushtin e që ekziston një rresht i caktuar në mesazhin e komitetit,
• dërgimin e paketave të ndërtuara në një feed privat në Azure DevOps,
• ndërtimin e dokumentacionit dhe publikimin në GitLab Pages,
• badge!11

Kërkesat e përshkruara përshtaten organikisht me modelin e mëposhtëm të pipeline-it:

• Faza 1 — ndërtimi
  • Ndërtojmë kodin, publikojmë skedarët e dalës si artefakte
• Faza 2 — testimi
  • Marrim artefaktet nga faza e ndërtimit, ekzekutojmë testet, grumbullojmë të dhënat e mbulimit të kodit
• Faza 3 — dërgimi
  • Detyra 1 — ndërtojmë një paketë nuget dhe dërgojmë në Azure DevOps
  • Detyra 2 — ndërtojmë një site nga xmldoc në kodin burimor dhe publikojmë në GitLab Pages

Le të fillojmë!

Dërgojmë konfiguracionin

Përgatitim llogaritë

1. Krijojmë një llogari në Microsoft Azure

2. Kalojmë te Azure DevOps

3. Krijojmë një projekt të ri

   1. Emri — çfarëdo
   2. Dukshmëria — çfarëdo
      

4. Kur të klikoni butonin Create projekti do të krijohet dhe do të kaloni në faqen e tij. Në këtë faqe mund të çaktivizoni mundësitë e panevojshme, duke shkuar në konfigurimet e projektit (lidhja e poshtme në listën e majtë -> Overview -> blloku i Shërbimeve Azure DevOps)
   

5. Shkojmë në Atrifacts, klikojmë Create feed

   1. Shkruajmë emrin e burimit
   2. Zgjidhim dukshmërinë
   3. Çaktivizojmë kutinë Përfshij paketat nga burime publike të zakonshme, në mënyrë që burimi të mos shndërrohet në një plehrash nën klonimin e nuget
      

6. Klikojmë Connect to feed, zgjidhim Visual Studio, nga blloku Machine Setup kopjojmë Source
   

7. Shkojmë në konfigurimet e llogarisë, zgjidhim Personal Access Token
   

8. Krijojmë një token të ri akses

   1. Emri — i rastësishëm
   2. Organizata — aktuale
   3. Afati i skadimit — maksimumi 1 vit
   4. Fusha e veprimit (scope) — Packaging/Read & Write
      

9. Kopjojmë tokenin e krijuar — pas mbylljes së dritares modale vlera nuk do të jetë e disponueshme

10. Hynë në konfigurimet e depozitës në GitLab, zgjidhni konfigurimet CI/CD
    

11. Zgjerojmë bllokun Variables, shtojmë një të re

    1. Emri — çfarëdo pa hapësira (do të jetë i disponueshëm në shell-in komandor)
    2. Vlera — tokeni i aksesit nga pika 9
    3. Zgjidhni Mask variable
       

Kjo është përfundimi i konfigurimit paraprak.

Përgatitim skeletin e konfigurimit

Sipas parazgjedhjes, për konfigurimin CI/CD në GitLab përdoret skedari .gitlab-ci.yml nga rrënja e depozitës. Mund të konfiguroni një rrugë të rastësishme deri në këtë skedar në konfigurimet e depozitës, por në këtë rast nuk është e nevojshme.

Siç duket nga shtesat, skedari përmban konfigurimin në formatin YAML. Dokumentacioni përshkruan hollësisht se cilat çelësa mund të jenë të pranishëm në nivelin e lartë të konfigurimit dhe në secilin nga nivelet e brendshme.

Fillohet duke shtuar në skedarin e konfigurimit një lidhje me imazhin docker, në të cilin do të realizohen detyrat. Për këtë, gjejmë faqen e imazheve .Net Core në Docker Hub. Në GitHub ka një udhëzues të hollësishëm se cili imazh të zgjidhet për detyra të ndryshme. Për ndërtimin, na përshtatet imazhi me .Net Core 3.1, prandaj e shtojmë guximshëm si rreshtin e parë në konfigurim

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

Tani, kur startohet pipeline nga depoja e imazheve Microsoft, do të shkarkohet imazhi i caktuar, në të cilin do të realizohen të gjitha detyrat nga konfigurimi.

Hapi tjetër — shtoni ) — një njësi organizimi e pipeline-it, përmban 1+ detyrë,‘ë. Sipas parazgjedhjes, GitLab përcakton 5 etapa:

• .pre — kryhet para të gjitha etapave,
• .post — kryhet pas të gjitha etapave,
• build — e para pas .pre etapës,
• test — etapa e dytë,
• deploy — etapa e tretë.

Nuk ka asgjë që ndalon shprehjen e tyre qartësisht, megjithatë. Renditja në të cilën përmenden etapet ndikon në renditjen e ekzekutimit të tyre. Për plotësinë e përshkrimit, do të shtojmë në konfigurim:

stages:
  - build
  - test
  - deploy

Për debug, ka kuptim të merren informacion mbi mjedisin ku realizohen detyrat. Shtojmë një grup global komandash, që do të kryhen përpara çdo detyre, me anë të before_script:

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

Ka mbetur të shtojmë të paktën një detyrë, që kur dërgohen komitetet, pipeline të startohet. Deri tani, do të shtojmë një detyrë të zbrazët për demonstrim:

dummy job:
  script:
    - echo ok

Nisimë validimin, marrim një mesazh që gjithçka është mirë, komitojmë, e dërgojmë, shohim rezultatet në faqe... Dhe marrim një gabim në skriptë — bash: .PSVersion: komanda nuk u gjet. Çfarë ndodhi?

E gjitha ka kuptim — për default, runner'ët (të cilët janë përgjegjës për ekzekutimin e skripteve të detyrave dhe ofrohen nga GitLab) përdorin bash për ekzekutimin e komandave. Mund ta rregullojmë këtë duke specifikuar qartë në përshkrimin e detyrës, cilat etiketa duhet të ketë runner’i që ekzekuton pipeline-in:

detyrë dummy në windows:
  skript:
    - echo ok
  etiketa:
    - windows

Super! Tani pipeline-i po ekzekutohet.

Lexuesi i kujdesshëm, duke përsëritur hapat e përmendur, do të vërejë se detyra u ekzekutua në fazën test, megjithëse ne nuk e caktuam ndonjë fazë. Siç mund të merret me mend, test është faza e default.

Të vazhdojmë me krijimin e skeletit të konfiguracionit, duke shtuar të gjitha detyrat e përshkruara më lart:

detyrë ndërtimi:
  skript:
    - echo "ndërto..."
  etiketa:
    - windows
  faza: ndërtim

testim dhe mbulim:
  skript:
    - echo "duke ekzekutuar testet dhe analizën e mbulimit..."
  etiketa:
    - windows
  faza: testim

paketim dhe dërgim:
  skript:
    - echo "duke paketa dhe dërguar në nuget..."
  etiketa:
    - windows
  faza: dërgim

faqet:
  skript:
    - echo "duke krijuar dokumente..."
  etiketa:
    - windows
  faza: dërgim

Mora një pipeline që nuk është shumë funksional, por megjithatë korrekt.

Konfigurimi i triggereve

Për shkak se për asnjë nga detyrat nuk janë specifikuar filtrat e aktivizimit, pipeline do të plotësisht ekzekutohet me çdo dërgesë komit në republikë. Duke qenë se kjo nuk është një sjellje e dëshiruar në përgjithësi, ne do të konfigurim filtrat e aktivizimit për detyrat.

Filtrat mund të konfiguroren në dy formate: vetëm/pa dhe rregullat. Në përmbledhje, vetëm/pa lejon konfigurimin e filtrave sipas triggereve (merge_request, për shembull — konfigurimi i detyrës për t'u ekzekutuar për çdo krijim të një kërkese për bashkim dhe për çdo dërgesë komitesh në degën që është burimi në kërkesën për bashkim) dhe emrat e degëve (përfshirë përdorimin e shprehjeve regula); rregullat lejon konfigurimin e një grupi kushtesh dhe, opsionalisht, ndryshimin e kushtit të ekzekutimit të detyrës sipas suksesit të detyrave të mëparshme (when në GitLab CI/CD).

Le të rikujtojmë setin e kërkesave — ndërtimi dhe testimi vetëm për merge request, paketimi dhe dërgimi në Azure DevOps — për merge request dhe dërgimet në master, gjenerimi i dokumentacionit — për dërgimet në master.

Për të filluar, do të konfiguroni detyrën e ndërtimit të kodit, duke shtuar një rregull aktivizimi vetëm për merge request:

detyrë ndërtimi:
  # snip
  vetëm:
    - merge_request

Tani do të konfigurojmë detyrën e paketimit për t'u aktivizuar në merge request dhe shtimin e komiteteve në master:

pakuar dhe instalo punën:
  # snip
  vetëm:
    - kërkesë bashkimi
    - master

Siç duket, gjithçka është e thjeshtë dhe e drejtpërdrejtë.

gjithashtu mund të konfigurohet detyra për të u aktivizuar vetëm nëse është krijuar një kërkesë bashkimi me një degë të caktuar target ose fillestare:

  rregulla:
    - nëse: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

Në kushtet mund të përdoren variablat e përmendura këtu; rregullat rregullat nuk janë të përputhshme me rregullat vetëm/pa.

Konfigurimi i ruajtjes së artefakteve

Gjatë ekzekutimit të detyrës punë ndërtimi do të krijojmë artefakte ndërtimi, të cilat mund të ripërdoren në detyra të ardhshme. Për këtë, ne duhet të shtojmë në konfigurimin e detyrës rrugët, skedarët që duhen ruajtur dhe ripërdorur në detyrat e ardhshme, në çelësin artefakte:

punë ndërtimi:
  # snip
  artefakte:
    rrugë:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

Rrugët mbështesin wildcards, që me siguri e thjeshton përcaktimin e tyre.

Nëse detyra krijon artefakte, atëherë çdo detyrë e ardhshme do të mund ti qasje — ato do të vendosen në të njëjtat rrugë në raport me rrënjën e depozitës, siç u krijuan nga detyra fillestare. Gjithashtu, artefaktet janë të disponueshme për shkarkim në sit.

Tani, kur kemi përgatitur (dhe verifikuar) skeletin e konfiguracionit, mund të kalojmë në faktin e shkruar të skriptet për detyrat.

Shkruajmë skriptet

Mund të ketë qenë dikur, në një galaksi të largët, ndërtimi i projekteve (përfshirë edhe në .net) nga linja e komandës ishte një dhimbje. Tani, mund ta ndërtojmë, testojmë dhe publikojmë projektin me 3 komanda:

dotnet build
dotnet test
dotnet pack

Natyrisht, ka disa nuanca që na bëjnë t'i komplikojmë disi komandat.

1. Ne duam një ndërtim për lëshim, e jo ndërtim për debugging, prandaj në çdo komandë shtojmë -c Release
2. Gjatë testimit, ne duam të grumbullojmë të dhëna për mbulimin e kodit, prandaj do të duhet të lidhim analizuesin e mbulimit në bibliotekat testuese:
   1. Çdo bibliotekë testuese duhet të shtojë paketën coverlet.msbuild: dotnet add package coverlet.msbuild nga folderi i projektit
   2. Në komandën e ekzekutimit të testeve do të shtojmë /p:CollectCoverage=true
   3. Në konfigurimin e detyrës së testimit do të shtojmë një çelës për të marrë rezultatet e mbulimit (shih më poshtë)
3. Kur paketojmë kodin në paketa nuget, do të përcaktojmë drejtorinë e daljes për paketat: -o .

Grumbullimi i të dhënave për mbulimin e kodit

Coverlet pas ekzekutimit të testeve nxjerr në konsolë statistikat mbi ekzekutimin:

Duke rezultatet e mbulimit...
  Duke gjeneruar raportin 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Moduli      | Linja   | Degë    | Metoda |
+-------------+--------+--------+--------+
| projekti 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| projekti 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| projekti 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Linja   | Degë    | Metoda |
+---------+--------+--------+--------+
| Totali   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Mesatarja | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

GitLab lejon të specifikoni një shprehje të rregullt për të marrë statistika, të cilat mund të merren pastaj në formën e një badge. Shprehja e rregullt jepet në cilësimet e detyrës me çelësin coverage; në shprehje duhet të jetë e pranishme një grup kaptejnë, vlera e të cilit do të kalojë në badge:

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

Këtu ne marrim statistika nga rreshti me mbulimin total për linjat.

Publikojmë paketat dhe dokumentacionin

Të dyja veprimet janë caktuar në etapën e fundit të pipeline-it — për sa kohë që ndërtimi dhe testet kaluan, mund të ndajmë edhe punimet me botën.

Së pari, le të shqyrtojmë publikimin në burimin e paketave:

1. Nëse projekti nuk ka një skedar konfigurimi nuget (nuget.config), le të krijojmë një të ri: dotnet new nugetconfig

   Pse: në imazh mund të jetë e ndaluar qasja në përgjithësi në konfigurimet globale (të përdoruesit dhe të makinës). Për të mos kapur gabime, le të krijojmë një konfigurim lokal të ri dhe të punojmë me të.

2. Le të shtojmë në konfigurimin lokal një burim të ri paketash: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
   1. emri — emri lokal i burimit, nuk ka rëndësi
   2. url — URL e burimit nga etapa "Përgatitja e llogarive", p. 6
   3. organization — emri i organizatës në Azure DevOps
   4. gitlab variable — emri i variablës me tokenin e qasjes, e shtuar në GitLab ("Përgatitja e llogarive", p. 11). Natyrisht, në formatin $variableName
   5. -StorePasswordInClearText — hack për të anashkaluar gabimin e refuzimit të qasjes (nuk jam i pari që ka hasur në këto thikë)
   6. Në rast të gabimeve, mund të jetë e dobishme të shtoni -verbosity detailed
3. Dërgo paketën në burimin: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
   1. Dërgojmë të gjitha paketat nga direktoria aktuale, kështu që *.nupkg.
   2. emri — nga hapi më sipër.
   3. key — çdo varg. Në Azure DevOps në dritaren Connect to feed gjithmonë japin si shembull vargun az.
   4. -skipduplicate — kur përpjekjen për të dërguar një paketë ekzistuese pa këtë çelës, burimi do të kthejë një gabim 409 Konflikt; me çelësin dërgimi do të përjashtohet.

Tani do të konfigurojmë krijimin e dokumentacionit:

1. Së pari, në depo, në degën master, inicializojmë projektin docfx. Për këtë, nga rrënja duhet të ekzekutojmë komandën docfx init dhe në mënyrë interaktive të vendosim parametrat kyç për ndërtimin e dokumentacionit. Një përshkrim i detajuar i konfigurimit minimal të projektit këtu.
   1. Kur bëni konfigurimin, është e rëndësishme të tregoni direktorine e daljes ..public — GitLab për default merr përmbajtjen e dosjes public në rrënjën e depozitës si burim për Pages. Për shkak se projekti do të jetë në një dosje të brendshme të depozites — shtojmë në rrugë të daljes një nivel lart.
2. Do të dërgojmë ndryshimet në GitLab.
3. Në konfigurimin e pipeline-it do të shtojmë një detyrë pages (fjalë e rezervuar për detyrat e publikimit të faqeve në GitLab Pages):
   1. Skema:
      1. nuget install docfx.console -version 2.51.0 — do të instalojë docfx; versioni është i caktuar për garancinë e saktësisë së rrugëve të instalimit të paketës.
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json — mbledhim dokumentacionin
   2. Nod arti:

pages:
  # snip
  artifacts:
    paths:
      - public

Një shpjegim letrar për docfx

Më herët, kur konfiguroja projektin, unë caktova burimin e kodit për dokumentacionin si një skedar zgjidhje. Disavantazhi kryesor — dokumentacioni krijohet edhe për projektet testuese. Nëse kjo nuk është e nevojshme, mund të caktosh një vlerë të tillë nodit metadata.src:

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

1. metadata.src.src: "..\/" — dalim një nivel lart në raport me vendndodhjen docfx.json, për shkak se në modele nuk punon kërkimi lart në pemën e direktorive.
2. metadata.src.files: ["**\/*.csproj"] — model global, mbledhim të gjitha projektet C# nga të gjitha direktorive.
3. metadata.src.exclude: ["*.tests*\/**"] — model global, përjashtojmë gjithçka nga dosjet me .tests në emër

Përfundimi mesatar

Një konfigurim kaq të thjeshtë mund ta hartosh dosido brenda gjysmë ore dhe një apo dy filxhanë kafe, i cili do të lejojë që për çdo kërkesë të bashkimit dhe dërgimi në master të kontrollohet se kodi ndërtohet dhe testet kalojnë, të mbledhim një paketë të re, të përditësojmë dokumentacionin dhe të kënaqim syrin me simbolika të bukura në README të projektit.

Përfundimi .gitlab-ci.yml

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

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

stadet:
  - ndërtim
  - test
  - deploy

punët e ndërtimit:
  stad: ndërtim
  skript:
    - dotnet build -c Release
  etiketat:
    - windows
  vetëm:
    - merge_requests
    - master
  artefakte:
    rrugët:
      - your/path/to/binaries

testimi dhe puna e mbulimit:
  stad: test
  etiketat:
    - windows
  skript:
    - dotnet test -c Release /p:CollectCoverage=true
  mbulimi: /|s*Totals*|s*(d+[,.]d+%) /
  vetëm:
    - merge_requests
    - master

paketa dhe punët e dërgimit:
  stad: deploy
  etiketat:
    - windows
  skript:
    - 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
  vetëm:
    - master

faqet:
  etiketat:
    - windows
  stad: deploy
  skript:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artefakte:
    rrugët:
      - public
  vetëm:
    - master

Përveç atyre badges

Pikërisht për këtë gjithçka është planifikuar!

Badges me statuset e pipeline dhe mbulimin e kodit janë të disponueshme në GitLab në cilësimet CI/CD në bllokun e Pipeline-ve:

Badges me lidhjen në dokumentacion e kam krijuar në platformën Shields.io — atje është mjaft e drejtpërdrejtë, mund të krijosh një badge tënden dhe ta marrësh atë përmes një kërkese.

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

Azure DevOps Artifacts gjithashtu lejon krijimin e badges për paketat me specifikimin e versionit aktual. Për këtë, në burimin e faqes Azure DevOps duhet të klikosh në Create badge për paketën e zgjedhur dhe të kopjosh markdown-in:

Shtojmë bukuri

Dallohemi fragmente të zakonshme të konfigurimit

Gjatë shkruarjes së konfigurimit dhe kërkimeve në dokumentacion, kam hasur një mundësi interesante YAML — rishfrytëzimin e fragmenteve.

Siç shihet nga cilësimet e detyrave, të gjitha kërkojnë një tag windows në runner dhe funksionojnë kur dërgohet në master/krijohet një kërkesë për bashkim (përveç dokumentacionit). Ta shtojmë këtë në fragmentin që do të rishfrytëzojmë:

.common_tags: &common_tags
  tags:
    - windows
.common_only: &common_only
  vetëm:
    - merge_requests
    - master

Dhe tani në përshkrimin e detyrës mund të inserojmë fragmentin e shpallur më parë:

punët e ndërtimit:
  <<: *common_tags
  <<: *common_only

Emrat e fragmenteve duhet të fillojnë me pikë, në mënyrë që të mos interpretohen si detyra.

Versionimi i paketave

Kur krijohet një paketë, kompajleri kontrollon çelësat e komandës dhe, në mungesë të tyre, skedarët e projekteve; duke gjetur nyjën Version, ai e merr vlerën e saj si versionin e paketës që po krijohet. Pra, për të ndërtuar një paketë me një version të ri, duhet ose ta përditësojmë atë në skedarin e projektit, ose ta kalojmë si një argument të komandës.

Të shtojmë një dëshirë tjetër — le të jenë dy numrat më të ulët në version vitin dhe datën e ndërtimit të paketës, dhe të shtojmë versionet para-lançimit. Sigurisht që mund t'i shtojmë këto të dhëna në skedarin e projektit dhe t'i kontrollojmë para secilës dorëzim — por mund ta bëjmë edhe në pipeline, duke e ndërtuar versionin e paketës nga konteksti dhe duke e kaluar përmes një argumenti të komandës.

Le të dakordohemi se, nëse në mesazhin e commit-it ka një varg si release (v. /ver./version) <version number> (rev./revision <revision>)?, atëherë ne do ta marrim versionin e paketës nga ky varg, do ta plotësojmë me datën aktuale dhe do ta kalojmë si një argument për komandën dotnet pack. Në mungesë të vargut — thjesht nuk do ta ndërtoshim paketën.

Ky problem zgjidhet nga skripti i mëposhtëm:

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

Shtojmë skriptin në detyrën pack and deploy job dhe vëzhgojmë ndërtimin e pakove vetëm nëse ka një varg të caktuar në mesazhin e commit-it.

Përveç kësaj

Pas rreth gjysmë ore deri në një orë kohë të kaluar në shkruarjen e konfiguracionit, debagimin në powershell lokal dhe, ndoshta, disa ekzekutimeve pa sukses, morëm një konfiguracion të thjeshtë për automatizimin e detyrave rutinë.

Sigurisht, GitLab CI/CD është shumë më i gjerë dhe më kompleks se sa mund të duket pas leximit të këtij udhëzuesi — kjo nuk është aspak e vërtetë. Aty madje Auto DevOps ekziston, që lejon

automatically detect, build, test, deploy, and monitor your applications

Tani në planet — të konfigurojmë pipeline për shpërndarjen e aplikacioneve në Azure, duke përdorur Pulumi dhe automatikisht duke e përcaktuar ambientin e synuar, që do të përshkruhet në artikullin e ardhshëm.

Burimi: habr.com