Udhëzues për CI/CD në GitLab për (gati) të sapoardhurin

Ose si të fitosh një etiketë të bukur për projektin tuaj gjatë një mbrëmjeje të relaksuar kodimi

Po, sigurisht, çdo zhvillues që ka së paku një projekt të vogël në një moment ndjen nevojën për etiketa të bukura me statuset, mbulimin e kodit, versionet e pacakave në nuget... Dhe ajo nevojë më çoi të shkruaj këtë artikull. Gjatë përgatitjeve për shkruarjen e tij, arrita të krijoj këtë bukuri në një nga projektet e mia:

Ky artikull do të shqyrtojë konfigurimin bazik të integrimit dhe furnizimit të vazhdueshëm për një projekt biblioteke 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 ke dërguar, dhe klienti tashmë ka pësuar dështim?

Çfarë është CI/CD dhe përse është e nevojshme — mund të gjesh lehtë në Google. Gjetja e dokumentacionit të plotë për konfigurimin e pipeline-ve në GitLab po ashtu nuk është e vështirë ashtu siç është e lehtë.. Këtu do të përshkruaj shkurtimisht dhe pa shumë defekte procesin e punës së sistemit nga një lartësi,

• zhvilluesi dërgon një komitet në repository, krijon një kërkesë bashkimi përmes faqes së internetit, ose në një mënyrë tjetër hapnisht ose pa e kuptuar aktivizon pipeline-in,
• nga konfigurimi përzgjidhen të gjitha detyrat, kushtet e të cilave lejojnë aktivizimin e tyre në këtë kontekst,
• detyrat organizohen sipas fazave të tyre,
• fazat gjithashtu realizohen njëra pas tjetrës, - dmth. paralelisht realizohen të gjitha detyrat e kësaj faze,
• nëse faza përfundon me dështim (dmth. përfundon me dështim të paktën një nga detyrat e fazës) - pipeline-i ndalet (në shumicën e rasteve),
• nëse të gjitha fazat përfundojnë me sukses, pipeline-i konsiderohet se ka kaluar me sukses.

Kështu, kemi:

• pipeline-i është një grup detyrash të organizuara në faza, në të cilin mund të grumbullohet, testohet, paketohen kodet, dhe të implementohet ndërtimi përfundimtar në një shërbim cloud, etj.
• fazë (stage) - një njësi organizimi e pipeline-it, përmban 1+ detyrë,
• detyrë (job) - një njësi pune në pipeline. Përbëhet nga një skript (patjetër), kushtet e aktivizimit, konfigurimet e publikimit/dhënies së artefakteve dhe shumë gjëra të tjera.

Prahashtmimi i CI/CD përfshin krijimin e një grupi detyrash që realizojnë të gjitha 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 pet, ato në GitHub ishin me pagesë, ndërsa unë isha i kujdesshëm. Depot u bënë falas, por akoma nuk është një arsye e mjaftueshme për të kaluar në GitHub.

• Pse jo Azure DevOps Pipelines?

Sepse konfigurimi është i thjeshtë — nuk kërkon njohuri të komandës së linjës. Integrimi me ofruesit e jashtëm git — ndodh në disa klikime, importimi i çelësave SSH për dërgimin e komiteteve në depo — gjithashtu, pipeline njëkohësisht konfigurues pa nevojën e një shablon.

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

Kemi:

• depo në GitLab.

Dëshirojmë:

• ndërtim dhe testim automatik për çdo kërkesë bashkimi,
• ndërtim paketash për çdo kërkesë bashkimi dhe në master me kusht që mesazhi i commitit të ketë një varg të caktuar,
• dërgimin e paketave të ndërtuara në një feed privat në Azure DevOps,
• ndërtimin e dokumentacionit dhe publikimin në GitLab Pages,
• badgje!11

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

• Hapi 1 — ndërtimi
  • Ngrijmë kodin, publikojmë skedarët rezultantë si artefakte
• Hapi 2 — testimi
  • Marrim artefaktet nga hapi i ndërtimit, ekzekutojmë testet, mbledhim të dhënat e mbulimit të kodit
• Hapi 3 — dërgimi
  • Detyra 1 — krijojmë paketën nuget dhe e dërgojmë në Azure DevOps
  • Detyra 2 — mbledhim faqen nga xmldoc në kodin burimor dhe e publikojmë në GitLab Pages

Le të fillojmë!

Krijojmë konfigurimin

Përgatitim llogaritë

1. Krijojmë një llogari në Microsoft Azure

2. Kalojmë në Azure DevOps

3. Krijojmë një projekt të ri

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

4. Me klikimin në butonin Create, projekti do të krijohet dhe do të kalojmë në faqen e tij. Në këtë faqe mund të çaktivizoni mundësitë e panevojshme, duke kaluar në cilësimet e projektit (linku në fund të listës së majtë -> Overview -> blloku i Shërbimeve Azure DevOps)
   

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

   1. Shkruajmë emrin e burimit
   2. Zgjidhim dukshmërinë
   3. Heqim shenjën Include packages from common public sources, për të mos e kthyer burimin në një pleh të ngjashëm me nuget
      

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

7. Shkijmë në cilësimet e llogarisë, zgjedhim Personal Access Token
   

8. Krijojmë një token të ri aksesit

   1. Emri — çfarëdo
   2. Organizata — aktuale
   3. Kohëzgjatja — maksimumi 1 vit
   4. Fusha e veprimit (scope) — Packaging/Read & Write
      

9. Po kopjojmë token-in e krijuar — pas mbylljes së dritares modale, vlera nuk do të jetë më e disponueshme

10. Hyr në cilësimet e depozitës në GitLab, zgjedh cilësimet CI/CD
    

11. Zgjero bllokun Variables, shto të re

    1. Emri — çfarëdo pa hapësira (do të jetë e disponueshme në terminal)
    2. Vlera — token-i i aksesit nga p. 9
    3. Zgjidh Mask variable
       

Me këtë përfundon konfigurimi paraprak.

Përgatitim kornizën e konfigurimit

Në mënyrë të paracaktuar, për konfigurimin CI/CD në GitLab përdoret skedari .gitlab-ci.yml nga rrënja e depozitës. Mund të konfigurosh një rrugë të rastësishme deri në këtë skedar në cilësimet e depozitës, por në këtë rast nuk është e nevojshme.

Siç shihet nga zgjerimi, skedari përmban konfigurimin në formatin YAML. Në dokumentacion përshkruhet në detaje se cilat çelësa mund të përmbahen në nivelin e sipërm të konfigurimit, dhe në secilin nga nivelet e brendshme.

Së pari, do të shtojmë në skedarin e konfigurimit lidhjen me imazhin docker, në të cilin do të kryhen detyrat. Për këtë, gjej faqen e imazheve .Net Core në Docker Hub. Në GitHub ka një udhëzues të detajuar se cili imazh të zgjidhni për detyra të ndryshme. Na ne, për ndërtim do të përkthehet imazhi me .Net Core 3.1, prandaj mund të shtojmë me guxim rreshtin e parë në konfigurim.

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

Tani, kur të filloni pipeline-in me magazinën e imazheve Microsoft, do të shkarkohet imazhi i specifikuar, në të cilin do të ekzekutohen të gjitha detyrat nga konfigurimi.

Hapi tjetër — të shtojmë stageetapa. Në mënyrë të paracaktuar, GitLab përcakton 5 etapa:

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

Nuk ka asgjë që të pengojë ta deklaroni ato qartë. Rendi në të cilin janë specifikuar etapat ndikon në rendin në të cilin ato ekzekutohen. Për plotësinë e përmbajtjes, do të shtojmë në konfigurim:

stages:
  - build
  - test
  - deploy

Për debugim ka kuptim të merrni informacion mbi mjedisin në të cilin ekzekutohen detyrat. Do të shtojmë një grup komandash globale, të cilat do të ekzekutohen para çdo detyre, me anë të before_script:

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

Duhet të shtoni të paktën një detyrë për të aktivizuar pipeline-n gjatë dërgimit të komiteteve. Për tani, le të shtojmë një detyrë të zbrazët për demonstrim:

detyrë shembuj:
  skript:
    - echo ok

Fillojmë validimin, marrim mesazhin që gjithçka është në rregull, komitojmë, shtyjmë, shohim rezultatet në faqe… Dhe marrim një gabim skripti — bash: .PSVersion: komandë e panjohur. WTF?

Çdo gjë ka kuptim — për default, runner-at (të cilët përgjigjen për ekzekutimin e skripteve të detyrave dhe ofrohen nga GitLab) përdorin bash për ekzekutimin e komandave. Këtë mund ta rregullojmë duke përcaktuar në përshkrimin e detyrës, cilat etiketa duhet të ketë runner-i i ekzekutimit të pipeline-it:

detyrë shembuj në windows:
  skript:
    - echo ok
  etiketat:
    - windows

Shkëlqyeshëm! Tani pipeline-i po ekzekutohet.

Një lexues i vëmendshëm, pas përsëritjes së hapave të përmendur, do të vërente se detyra u ekzekutua në fazën test, edhe pse ne nuk e kemi specifikuar fazën. Siç mund të supozojmë, test është faza e paracaktuar.

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

ndërtimi i punës:
  skenari:
    - echo "ndërtimi..."
  etiketat:
    - windows
  faza: ndërtim

testi dhe mbulimi i punës:
  skenari:
    - echo "ekzekutimi i testeve dhe analizës së mbulimit..."
  etiketat:
    - windows
  faza: test

paketimi dhe dërgimi i punës:
  skenari:
    - echo "paketimi dhe dërgimi në nuget..."
  etiketat:
    - windows
  faza: dërgo

faqet:
  skenari:
    - echo "krijimi i dokumenteve..."
  etiketat:
    - windows
  faza: dërgo

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

Konfigurimi i aktivizuesve

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ë të komiteteve në repository. Duke qenë se kjo nuk është sjellja e dëshiruar në përgjithësi, do të konfigurojmë filtrat e aktivizimit për detyrat.

Filtrat mund të konfigurohen në dy formate: only/except dhe rregulla. Në shkurt, only/except lejon konfigurimin e filtrave sipas aktivizuesve (merge_request, për shembull — konfigurimi i detyrës për t'u ekzekutuar me çdo krijim të një kërkese për bashkim dhe me çdo dërgesë të komiteteve në degën që është origjinë në kërkesën për bashkim) dhe emrat e degëve (përfshirë përdorimin e shprehjeve të zakonshme); rregulla lejon konfigurimin e një grupi kushtesh dhe, opcionalisht, ndryshimin e kushtit të ekzekutimit të detyrës në varësi të suksesit të detyrave të mëparshme (when në GitLab CI/CD).

Le të kujtojmë grupin e kërkesave — ndërtimi dhe testimi vetëm për kërkesat e bashkimit, paketimi dhe dërgimi në Azure DevOps — për kërkesat e bashkimeve dhe shtypjet në master, gjenerimi i dokumentacionit — për shtypjet në master.

Fillimisht, le të konfiguroni detyrën e ndërtimit të kodit duke shtuar një rregull që aktivizohet vetëm kur ka kërkesë për bashkim:

build job:
  # snip
  only:
    - merge_request

Tani le të konfiguroni detyrën e paketimit për aktivizim në kërkesat e bashkimit dhe shtimin e komiteteve në master:

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

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

Gjithashtu, mund të konfiguroni detyrën të aktivizohet vetëm nëse është krijuar një kërkesë për bashkim me një degë të caktuar qëllimi ose origjine:

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

Në kushtet mund të përdoren këto variabla të listuara këtu; rregulla rregulla nuk janë të përshtatshme me rregullat only/except.

Konfigurimi i ruajtjes së artefakteve

Gjatë ekzekutimit të detyrës build job ne do të krijojmë artefaktet e ndërtimit, të cilat mund të ri-përdoren në detyrat e ardhshme. Për këtë, duhet të shtoni në konfigurimin e detyrës rrugët, skedarët që duhet të ruhen dhe ri-përdoren në detyrat e ardhshme, në çelësin artifacts:

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

Rrugët mbështesin wildcards, çka pa dyshim e thjeshton caktimin e tyre.

Nëse një detyrë krijon artefakte, çdo detyrë pasuese do të mund t'i aksesojë ato — ato do të jenë të vendosura në të njëjtët rrugë në raport me rrënjën e repository-t, siç u mblodhën nga detyra origjinale. Po ashtu, artefaktet janë të disponueshme për descargas në faqe.

Tani që kemi përfunduar (dhe verifikuar) kornizën e konfigurimit, mund të kalojmë në shkruan e skripteve për detyrat.

Shkruajmë skripte

Ndoshta, njëherë e një kohë, në një galaktikë të largët, grumbullimi i projekteve (përfshirë ato në .net) nga një linjë komandimi ishte një dhimbje. Aktualisht, megjithatë, grumbullimi, testimi dhe publikimi i një projekti mund të bëhet në 3 komanda:

dotnet build
dotnet test
dotnet pack

Natyrisht, ekzistojnë disa nuanca për shkak të cilave ne do ta komplikohem pak komandat.

1. Dëshirojmë një ndërtim release, e jo një ndërtim debug, ndaj i shtojmë secilës komandë -c Release
2. Kur testojmë, duam të mbledhim të dhëna mbi mbulimin e kodit, prandaj do të nevojitet të lidhim një analizues mbulimi në bibliotekat testuese:
   1. Duhet të shtoni paketën coverlet.msbuild: dotnet add package coverlet.msbuild nga dosja e projektit
   2. Shtojmë në ekipin e lançimit të testeve /p:CollectCoverage=true
   3. Shtojmë në konfigurimin e detyrës së testeve një çelës për të marrë rezultatet e mbulimit (shih më poshtë)
3. Kur paketizojmë kodin në paketa nuget, do të caktojmë direktoriumin përfundimtar për paketat: -o .

Mblidhni të dhënat e mbulimit të kodit

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

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

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

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

GitLab lejon përcaktimin e një shprehje të rregullt për të marrë statistikat, të cilat mund të merren më pas si një badge. Shprehja e rregullt përcaktohet në cilësimet e detyrës me çelësin coverage; në shprehjen duhet të jetë e pranishme një grup kapës, vlera e të cilit do të transmetohet në badge:

testo dhe mbulo punën:
  # snip
  mbulimi: /|s*Totals*|s*(d+[,.]d+%)/

Këtu marrim statistikën nga rreshti me mbulimin e përgjithshëm sipas linjave.

Publikojmë paketat dhe dokumentacionin

Të dy veprimet tona janë caktuar në fazën e fundit të pipeline-it — pasi ndërtimi dhe testet kaluan, mund të ndajmë me botën zhvillimet tona.

Për fillim, le të shqyrtojmë publikimin në burimin e paketave:

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

   Pse: në imazhin mund të jetë e ndaluar qasje me shkrim në konfigurimet globale (përdorues dhe makinë). Për të shmangur gabimet, thjesht të krijojmë një konfigurim lokal të ri dhe të punojmë me të.

2. Shtojmë në konfigurimin lokal një burim të ri paketash: nuget sources add -name -source -username -password -configfile nuget.config -StorePasswordInClearText
   1. emri — emri lokal i burimit, nuk ka rëndësi
   2. url — URL e burimit nga hapi "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 aksesit, i shtuar në GitLab ("Përgatitja e llogarive", p. 11). Natyrisht, në formatin $variableName
   5. -StorePasswordInClearText — hack për të shmangur gabimin e refuzimit të aksesit (nuk isha i pari që ra në këto gropa)
   6. Në rast gabimesh, mund të jetë e dobishme të shtoni -verbosity detailed
3. Po dërgojmë paketën në burim: nuget push -source -skipduplicate -apikey *.nupkg
   1. Po dërgojmë të gjitha paketat nga direktorja aktuale, për këtë *.nupkg.
   2. emri — nga hapi i mësipërm.
   3. key — çdo varg. Në Azure DevOps në dritaren Connect to feed gjithmonë jepet si shembull vargu az.
   4. -skipduplicate — kur përpiqeni të dërgoni një pako ekzistuese, pa këtë çelës burimi do të kthejë një gabim 409 Conflict; me çelësin dërgesa do të anashkalohet.

Tani të konfiguroni krijimin e dokumentacionit:

1. Fillimisht, në repository, në degën master, inicializoni projektin docfx. Për këtë, nga rrënja duhet të ekzekutoni komandën docfx init dhe në modin interaktiv do të caktoni parametrat kyç për ndërtimin e dokumentacionit. Përshkrimi i detajuar i konfigurimit minimal të projektit këtu.
   1. Kur konfiguroni, është e rëndësishme të përcaktoni direktorinë e daljes ..public — GitLab si rregull merr përmbajtjen e dosjes public në rrënjën e repository-t si burim për Pages. Duke qenë se projekti do të vendoset në një dosje brenda repository-t — e shtojmë në rrugë daljen një nivel më lart.
2. Do të dërgojmë ndryshimet në GitLab.
3. Në konfigurimin e pipeline-it do të shtojmë detyrën pages (fjalë e rezervuar për detyrat e publikimit të faqeve në GitLab Pages):
   1. Skripti:
      1. nuget install docfx.console -version 2.51.0 — do të instalojë docfx; versióni është specifikuar për të garantuar saktësinë e rrugëve të instalimit të paketës.
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json — duke ndërtuar dokumentacionin
   2. Nod’i artifacts:

pages:
  # snip
  artifacts:
    paths:
      - public

Një qasje letrare mbi docfx

Më parë, kur po konfiguronte projektin, unë specifikoja burimin e kodit për dokumentacionin si skedën e zgjidhjes. Mangësia kryesore — dokumentacioni krijohet gjithashtu për projektet e testimit. Nëse kjo nuk është e nevojshme, mund të caktosh një vlerë të tillë për nodin metadata.src:

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

1. metadata.src.src: "../" — dalim në nivelin lart në lidhje me vendndodhjen docfx.json, sepse në patternet nuk funksionon kërkimi lart në pemën e drejtorive.
2. metadata.src.files: ["**/*.csproj"] — pattern global, mbledhim të gjithë projektet C# nga të gjitha drejtoritë.
3. metadata.src.exclude: ["*.tests*/**"] — pattern global, përjashtojmë gjithçka nga folderët me .tests në emër

Një përfundim ndërmjetësi

Këtë konfigurim të thjeshtë mund ta realizoni në vetëm gjysmë ore dhe disa filxhanë kafe, i cili do të lejojë që me çdo kërkesë bashkimi dhe dërgimi në master të verifikohet se kodi kompilohet dhe provat kalojnë, të grumbullohet një paketë e re, të përditësohet dokumentacioni dhe të gëzojë sy më etiketat e bukura në README-n e projektit.

GitLab CI/CD përfundimtar

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

Në lidhje me etiketat

Për to ka filluar gjithçka!

Beadhet me statuset e pipeline-it dhe mbulimin e kodit janë të disponueshme në GitLab në cilësimet CI/CD në bllokun Gtntral pipelines:

Unë krijova beadhin me lidhje për dokumentacionin në platformën Shields.io — atje gjithçka është mjaft e drejtpërdrejtë, mund të krijoni beadhin tuaj dhe ta merrni atë me anë të një kërkese.

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

Azure DevOps Artifacts gjithashtu lejon krijimin e beadheve për paketat me caktimin e versionit aktual. Për këtë, në burimin në faqen e Azure DevOps duhet të klikoni mbi Create badge për paketën e zgjedhur dhe të kopjoni shenjat markdown:

Shtojmë bukuri

Dallohemi fraksionet e përbashkëta të konfigurimit

Gjatë shkruarjes së konfigurimit dhe kërkimeve në dokumentacion, ndesha një mundësi interesante në YAML — ri-shfrytëzimin e fraksioneve.

Siç tregohet në cilësimet e detyrave, të gjitha kërkojnë një etiketë windows tek runner-i, dhe veprojnë kur dërgohet në master/kur krijohet një kërkesë për bashkim (përveç dokumentacionit). Do ta shtojmë këtë në fraksionin që do të ri-shfrytëzojmë:

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

Dhe tani në përshkrimin e detyrës mund të vendosim fraksionin e shpallur më parë:

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

Emrat e fraksioneve duhet të fillojnë me një pikë, për të mos u interpretuar si një detyrë.

Versionimi i paketave

Kur krijohet një paketë, kompajleri kontrollon çelësat e komandës në linjë, dhe në mungesë të tyre — skedarët e projekteve; duke gjetur nodin Version, ai merr vlerën e tij si versionin e paketës që po ndërtohet. Kështu që, 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 transferojmë si një argument në komandën e linjës.

Të shtojmë një tjetër dëshirë — le të jenë dy numrat e fundit në version vitin dhe datën e ndërtimit të paketës, dhe të shtojmë versionet para-lëshimit. Sigurisht mund të shtojmë këto të dhëna në skedarin e projektit dhe t'i kontrollojmë para çdo dërgimi — por mund ta bëjmë këtë edhe në pipeline, duke ndërtuar versionin e paketës nga konteksti dhe duke e kaluar atë përmes një argumenti në komandën e linjës.

Le të pajtohemi se nëse në mesazhin e përditësimit ka një rresht të tipit release (v./ver./version) <numri i versionit> (rev./revizion <revision>)?, atëherë ne do të marrim versionin e paketës nga ky rresht, do ta plotësojmë me datën aktuale dhe do ta transferojmë si argument në komandën dotnet pack. Në mungesë të këtij rreshti — thjesht nuk do ta ndërtojmë paketën.

Ky skenar zgjidh këtë detyrë:

# регулярное выражение для поиска строки с версией
$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ë punë e paketimit dhe deploying dhe vëzhgojmë ndërtimin e paketave, vetëm nëse ka një rresht të caktuar në mesazhin e commit-it.

Në përfundim

Pasi kaluam rreth një gjysmë ore deri në një orë në shkruarjen e konfiguracionit, debug-in në powershell lokal, dhe ndoshta disa nisje jo të suksesshme, arritëm një konfiguracion të thjeshtë për automatizimin e detyrave rutinë.

Sigurisht, GitLab CI/CD është shumë më i gjerë dhe më shumëplanesh se sa mund të duket pas leximit të këtij udhëzuesi — nuk është aspak kështu. Aty madje Auto DevOps ekziston, duke lejuar

të zbulojë automatikisht, ndërtues, testojë, implementojë dhe monitorojë aplikacionet tuaja

Tani qëllimi është të konfigurohet një pipeline për implementimin e aplikacioneve në Azure, duke përdorur Pulumi dhe identifikimin automatik të ambientit që do të diskutohet në artikullin e ardhshëm.

Burimi: habr.com