🥇Udhëzues për CI/CD në GitLab për fillestarin (pothuajse) absolut

Ose si të merrni distinktivë të bukur për projektin tuaj në një mbrëmje kodimi të lehtë

Ndoshta, çdo zhvillues që ka të paktën një projekt për kafshët shtëpiake në një moment ka një kruarje për distinktivët e bukur me statuse, mbulimin e kodeve, versionet e paketave në nuget ... Dhe kjo kruarje më bëri të shkruaj këtë artikull. Në përgatitjen për ta shkruar, mora këtë bukuri në një nga projektet e mia:

Ky artikull do t'ju përcjellë konfigurimin bazë të integrimit dhe shpërndarjes së vazhdueshme për një projekt të bibliotekës së klasës .Net Core në GitLab, publikimin e dokumentacionit në Faqet GitLab dhe shtyrjen e paketave të ndërtuara në një furnizim privat në Azure DevOps.

VS Code u përdor si mjedis zhvillimi me shtesën Rrjedha e punës GitLab (për vërtetimin e skedarit të cilësimeve direkt nga mjedisi i zhvillimit).

Prezantim i shkurtër

CD - është kur sapo keni shtyrë, dhe gjithçka tashmë ka rënë mbi klientin?

Çfarë është CI / CD dhe pse ju nevojitet - mund ta kërkoni lehtësisht në google. Gjeni dokumentacion të plotë mbi konfigurimin e tubacioneve në GitLab gjithashtu e lehtë. Këtu do të përshkruaj shkurtimisht dhe, nëse është e mundur, pa të meta procesin e sistemit nga një këndvështrim zogu:

zhvilluesi dërgon një commit në depo, krijon një kërkesë për bashkim përmes faqes, ose në ndonjë mënyrë tjetër, në mënyrë eksplicite ose implicite nis tubacionin,
të gjitha detyrat zgjidhen nga konfigurimi, kushtet e të cilave lejojnë që ato të nisen në kontekstin e caktuar,
detyrat organizohen sipas fazave të tyre,
fazat ekzekutohen me radhë - d.m.th. paralele të gjitha detyrat e kësaj faze janë përfunduar,
nëse faza dështon (d.m.th., të paktën një nga detyrat e skenës dështon), tubacioni ndalon (pothuajse gjithmonë),
nëse të gjitha fazat përfundojnë me sukses, tubacioni konsiderohet i suksesshëm.

Kështu, kemi:

tubacion - një grup detyrash të organizuara në faza në të cilat mund të ndërtoni, testoni, paketoni kodin, të vendosni një ndërtim të përfunduar në një shërbim cloud, etj.,
fazë (fazë) — njësia organizative e tubacionit, përmban 1+ detyrë,
detyrë (punë) është një njësi e punës në tubacion. Ai përbëhet nga një skript (i detyrueshëm), kushtet e nisjes, cilësimet për botimin / ruajtjen e artefakteve dhe shumë më tepër.

Prandaj, detyra kur vendosni CI / CD zbret në krijimin e një grupi detyrash që zbatojnë të gjitha veprimet e nevojshme për ndërtimin, testimin dhe publikimin e kodit dhe objekteve.

Para se të filloni: pse?

Pse Gitlab?

Sepse kur u bë e nevojshme të krijoheshin depo private për projektet e kafshëve shtëpiake, ato paguheshin në GitHub dhe unë isha i pangopur. Depot janë bërë falas, por deri më tani kjo nuk është arsye e mjaftueshme që unë të kaloj në GitHub.

Pse jo tubacionet Azure DevOps?

Sepse atje vendosja është elementare - as nuk kërkohet njohuri për vijën e komandës. Integrimi me ofruesit e jashtëm git - me disa klikime, importimi i çelësave SSH për të dërguar angazhime në depo - gjithashtu, tubacioni konfigurohet lehtësisht edhe jo nga një shabllon.

Pozicioni fillestar: çfarë keni dhe çfarë dëshironi

Ne kemi:

depo në GitLab.

Ne duam:

montim dhe testim automatik për çdo kërkesë bashkimi,
ndërtimi i paketave për çdo kërkesë për bashkim dhe shtyrja drejt masterit, me kusht që të ketë një linjë të caktuar në mesazhin e kryerjes,
dërgimi i paketave të ndërtuara në një furnizim privat në Azure DevOps,
montimi i dokumentacionit dhe publikimi në GitLab Pages,
distinktivët!11

Kërkesat e përshkruara në mënyrë organike bien në modelin e mëposhtëm të tubacionit:

Faza 1 - montimi
- Ne mbledhim kodin, publikojmë skedarët e daljes si objekte
Faza 2 - testimi
- Ne marrim objekte nga faza e ndërtimit, kryejmë teste, mbledhim të dhëna të mbulimit të kodit
Faza 3 - Paraqisni
- Detyra 1 - ndërtoni paketën nuget dhe dërgojeni te Azure DevOps
- Detyra 2 - ne mbledhim faqen nga xmldoc në kodin burimor dhe e publikojmë atë në GitLab Pages

Le të fillojmë!

Mbledhja e konfigurimit

Përgatitja e llogarive

Krijo një llogari në Microsoft Azure
Shkoni në Azure DevOps
Ne krijojmë një projekt të ri
1. Emri - çdo
2. Dukshmëria - çdo
Kur klikoni në butonin Krijo, projekti do të krijohet dhe ju do të ridrejtoheni në faqen e tij. Në këtë faqe, mund të çaktivizoni veçoritë e panevojshme duke shkuar te cilësimet e projektit (lidhja e poshtme në listë në të majtë -> Përmbledhje -> Blloku i Shërbimeve Azure DevOps)
Shkoni te Atrifacts, klikoni Krijo furnizim
1. Shkruani emrin e burimit
2. Zgjidhni dukshmërinë
3. Hiq zgjedhjen Përfshini paketa nga burime të përbashkëta publike, në mënyrë që burimi të mos kthehet në një klon hale nuget
Kliko Lidhu për të ushqyer, zgjidhni Visual Studio, kopjoni Burimin nga blloku i konfigurimit të makinës
Shkoni te cilësimet e llogarisë, zgjidhni Personal Access Token
Krijo një shenjë të re aksesi
1. Emri - arbitrar
2. Organizimi - aktual
3. E vlefshme për maksimum 1 vit
4. Fushëveprimi - Paketimi/Lexo dhe shkruaj
Kopjoni shenjën e krijuar - pasi të mbyllet dritarja modale, vlera nuk do të jetë e disponueshme
Shkoni te cilësimet e depove në GitLab, zgjidhni cilësimet CI / CD
Zgjero bllokun Variablat, shto një të ri
1. Emri - çdo pa hapësira (do të jetë i disponueshëm në guaskën e komandës)
2. Vlera - shenja e hyrjes nga paragrafi 9
3. Zgjidhni variablin Maskë

Kjo përfundon konfigurimin paraprak.

Përgatitja e kornizës së konfigurimit

Si parazgjedhje, konfigurimi CI/CD në GitLab përdor skedarin .gitlab-ci.yml nga rrënja e depove. Ju mund të vendosni një shteg arbitrar për këtë skedar në cilësimet e depove, por në këtë rast nuk është e nevojshme.

Siç mund ta shihni nga shtesa, skedari përmban një konfigurim në format YAML. Dokumentacioni detajon se cilët çelësa mund të përmbahen në nivelin e sipërm të konfigurimit dhe në secilin nga nivelet e ndërlidhura.

Së pari, le të shtojmë një lidhje me imazhin e dokerit në skedarin e konfigurimit, në të cilin do të kryhen detyrat. Për këtë gjejmë Faqja e imazheve .Net Core në Docker Hub. Në GitHub ekziston një udhëzues i detajuar se cilin imazh të zgjidhni për detyra të ndryshme. Një imazh me .Net Core 3.1 është i përshtatshëm për ne për të ndërtuar, kështu që mos ngurroni të shtoni rreshtin e parë në konfigurim

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

Tani, kur tubacioni të nisë nga depoja e imazhit të Microsoft, imazhi i specifikuar do të shkarkohet, në të cilin do të ekzekutohen të gjitha detyrat nga konfigurimi.

Hapi tjetër është shtimi fazë's. Si parazgjedhje, GitLab përcakton 5 faza:

.pre - kryhet deri në të gjitha fazat,
.post - kryhet pas të gjitha fazave,
build - së pari pas .pre fazë,
test -faza e dytë,
deploy - faza e tretë.

Megjithatë, asgjë nuk ju pengon t'i deklaroni ato në mënyrë eksplicite. Rendi në të cilin janë renditur hapat ndikon në rendin në të cilin janë kryer. Për plotësinë, le t'i shtojmë konfigurimit:

stages:
  - build
  - test
  - deploy

Për korrigjimin, ka kuptim të merrni informacion në lidhje me mjedisin në të cilin ekzekutohen detyrat. Le të shtojmë një grup global komandash që do të ekzekutohen para çdo detyre me before_script:

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

Mbetet të shtohet të paktën një detyrë në mënyrë që kur të dërgohen angazhimet, të fillojë tubacioni. Tani për tani, le të shtojmë një detyrë boshe për të demonstruar:

dummy job:
  script:
    - echo ok

Ne fillojmë verifikimin, marrim një mesazh që gjithçka është në rregull, ne angazhohemi, shtyjmë, shikojmë rezultatet në sit ... Dhe marrim një gabim skripti - bash: .PSVersion: command not found. wtf?

Gjithçka është logjike - si parazgjedhje, vrapuesit (përgjegjës për ekzekutimin e skripteve të detyrave dhe të ofruara nga GitLab) përdorin bash për të ekzekutuar komandat. Ju mund ta rregulloni këtë duke specifikuar në mënyrë eksplicite në përshkrimin e detyrës se cilat etiketa duhet të ketë ekzekutuesi i tubacionit ekzekutues:

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

E madhe! Tubacioni tani po funksionon.

Një lexues i vëmendshëm, pasi ka përsëritur hapat e treguar, do të vërejë se detyra është përfunduar në fazë test, megjithëse nuk e kemi specifikuar fazën. Siç mund ta merrni me mend test është hapi i paracaktuar.

Le të vazhdojmë krijimin e skeletit të konfigurimit duke shtuar të gjitha detyrat e përshkruara më sipër:

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

Ne morëm një tubacion jo veçanërisht funksional, por megjithatë korrekt.

Vendosja e nxitësve

Për shkak të faktit se asnjë filtër nxitës nuk është specifikuar për asnjë nga detyrat, tubacioni do полностью të ekzekutohet sa herë që një commit shtyhet në depo. Meqenëse kjo nuk është sjellja e dëshiruar në përgjithësi, ne do të konfigurojmë filtrat e aktivizimit për detyrat.

Filtrat mund të konfigurohen në dy formate: vetëm/përveç и rregullat. Shkurtimisht, only/except ju lejon të konfiguroni filtrat sipas nxitësve (merge_request, për shembull - vendos detyrën që do të ekzekutohet sa herë që krijohet një kërkesë tërheqëse dhe sa herë që commits dërgohen në degën që është burimi në kërkesën për bashkim) dhe emrat e degëve (duke përfshirë përdorimin e shprehjeve të rregullta); rules ju lejon të personalizoni një grup kushtesh dhe, sipas dëshirës, të ndryshoni kushtin e ekzekutimit të detyrës në varësi të suksesit të detyrave të mëparshme (when në GitLab CI/CD).

Le të kujtojmë një sërë kërkesash - montim dhe testim vetëm për kërkesën për bashkim, paketim dhe dërgim te Azure DevOps - për kërkesën për bashkim dhe shtytje drejt masterit, gjenerimi i dokumentacionit - për shtytjet drejt masterit.

Së pari, le të konfigurojmë detyrën e krijimit të kodit duke shtuar një rregull që aktivizohet vetëm me kërkesën e bashkimit:

build job:
  # snip
  only:
    - merge_request

Tani le të konfigurojmë detyrën e paketimit për të aktivizuar kërkesën për bashkim dhe për të shtuar angazhime te masteri:

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

Siç mund ta shihni, gjithçka është e thjeshtë dhe e drejtpërdrejtë.

Ju gjithashtu mund ta vendosni detyrën të aktivizohet vetëm nëse krijohet një kërkesë për bashkim me një objektiv specifik ose degë burimi:

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

Në kushte, mund të përdorni variablat e renditur këtu; rregullat rules të papajtueshme me rregullat only/except.

Konfigurimi i ruajtjes së objektit

Gjatë një detyre build job do të kemi objekte ndërtimi që mund të ripërdoren në detyrat e mëvonshme. Për ta bërë këtë, duhet të shtoni shtigjet në konfigurimin e detyrës, skedarët përgjatë të cilave do t'ju duhet të ruani dhe ripërdorni në detyrat e mëposhtme, në çelësin artifacts:

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

Shtigjet mbështesin shkronjat e egra, gjë që padyshim e bën më të lehtë vendosjen e tyre.

Nëse një detyrë krijon artefakte, atëherë çdo detyrë pasuese do të jetë në gjendje t'i qaset ato - ato do të vendosen përgjatë të njëjtave shtigje në lidhje me rrënjën e depove që u mblodhën nga detyra origjinale. Artefaktet janë gjithashtu të disponueshme për shkarkim në sit.

Tani që kemi gati (dhe të testuar) kornizën e konfigurimit, mund të vazhdojmë të shkruajmë skriptet për detyrat.

Ne shkruajmë skenarë

Ndoshta, një herë e një kohë, në një galaktikë shumë larg, ndërtimi i projekteve (përfshirë ato në .net) nga linja e komandës ishte një dhimbje. Tani mund të ndërtoni, testoni dhe publikoni projektin në 3 ekipe:

dotnet build
dotnet test
dotnet pack

Natyrisht, ka disa nuanca për shkak të të cilave ne do të komplikojmë disi komandat.

Ne duam një version të lëshimit, jo një ndërtim korrigjimi, kështu që ne i shtojmë çdo komande -c Release
Gjatë testimit, ne duam të mbledhim të dhëna të mbulimit të kodit, kështu që duhet të përfshijmë një analizues mbulimi në bibliotekat e testimit:
1. Shtoni paketën në të gjitha bibliotekat e testimit coverlet.msbuild: dotnet add package coverlet.msbuild nga dosja e projektit
2. Shtoni në komandën e ekzekutimit të testit /p:CollectCoverage=true
3. Shtoni një çelës në konfigurimin e detyrës së provës për të marrë rezultatet e mbulimit (shih më poshtë)
Kur paketoni kodin në paketat nuget, vendosni direktorinë e daljes për paketat: -o .

Mbledhja e të dhënave të mbulimit të kodit

Pas ekzekutimit të testeve, Coverlet printon statistikat e ekzekutimit në tastierë:

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 ju lejon të specifikoni një shprehje të rregullt për të marrë statistika, të cilat më pas mund të merren në formën e një distinktiv. Shprehja e rregullt specifikohet në cilësimet e detyrës me tastin coverage; shprehja duhet të përmbajë një grup kapjeje, vlera e të cilit do t'i kalohet distinktivit:

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

Këtu marrim statistika nga një linjë me mbulim total të linjës.

Publikimi i paketave dhe dokumentacionit

Të dy veprimet janë planifikuar për fazën e fundit të tubacionit - meqenëse montimi dhe testet kanë kaluar, ne mund t'i ndajmë zhvillimet tona me botën.

Së pari, merrni parasysh publikimin në burimin e paketës:

Nëse projekti nuk ka një skedar konfigurimi nuget (nuget.config), krijoni një të re: dotnet new nugetconfig

Per cfare: imazhi mund të mos ketë akses shkrimi në konfigurimet globale (përdorues dhe makinë). Për të mos kapur gabime, ne thjesht krijojmë një konfigurim të ri lokal dhe punojmë me të.
Le të shtojmë një burim të ri pakete në konfigurimin lokal: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - Emri i burimit lokal, jo kritik
2. url - URL-ja e burimit nga faza "Përgatitja e llogarive", f. 6
3. organization - emri i organizatës në Azure DevOps
4. gitlab variable - emri i ndryshores me shenjën e aksesit të shtuar në GitLab ("Përgatitja e llogarive", f. 11). Natyrisht, në format $variableName
5. -StorePasswordInClearText - një hak për të anashkaluar gabimin e mohuar qasja (Unë nuk jam i pari që shkel këtë grabujë)
6. Në rast gabimesh, mund të jetë e dobishme të shtoni -verbosity detailed
Dërgimi i paketës në burim: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Ne i dërgojmë të gjitha paketat nga drejtoria aktuale, kështu që *.nupkg.
2. name - nga hapi i mësipërm.
3. key - çdo linjë. Në Azure DevOps, në dritaren Connect to feed, shembulli është gjithmonë linja az.
4. -skipduplicate - kur përpiqeni të dërgoni një paketë tashmë ekzistuese pa këtë çelës, burimi do të kthejë një gabim 409 Conflict; me çelësin, dërgimi do të anashkalohet.

Tani le të vendosim krijimin e dokumentacionit:

Së pari, në depo, në degën master, ne inicializojmë projektin docfx. Për ta bërë këtë, ekzekutoni komandën nga rrënja docfx init dhe vendosni në mënyrë interaktive parametrat kryesorë për dokumentacionin e ndërtimit. Përshkrimi i detajuar i konfigurimit minimal të projektit këtu.
1. Kur konfiguroni, është e rëndësishme të specifikoni direktorinë e daljes ..public - GitLab si parazgjedhje merr përmbajtjen e dosjes publike në rrënjën e depove si burim për Faqet. Sepse projekti do të vendoset në një dosje të vendosur në depo - shtoni një dalje në nivelin lart në shteg.
Le të shtyjmë ndryshimet në GitLab.
Shtoni një detyrë në konfigurimin e tubacionit pages (fjalë e rezervuar për detyrat e publikimit të faqes në GitLab Pages):
1. Skript:
  1. nuget install docfx.console -version 2.51.0 - instaloni docfx; versioni është specifikuar për të siguruar që shtigjet e instalimit të paketës janë të sakta.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - mbledhjen e dokumentacionit
2. Artefaktet e nyjeve:

pages:
  # snip
  artifacts:
    paths:
      - public

Digresion lirik rreth docfx

Më parë, kur konfiguroja një projekt, unë specifikoja burimin e kodit për dokumentacionin si skedar zgjidhjeje. Disavantazhi kryesor është se dokumentacioni krijohet edhe për projektet e testimit. Në rast se kjo nuk është e nevojshme, mund ta vendosni këtë vlerë në nyjë metadata.src:

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

metadata.src.src: "../" - ne shkojmë një nivel më lart në lidhje me vendndodhjen docfx.json, sepse në modelet, kërkimi i pemës së drejtorisë nuk funksionon.
metadata.src.files: ["**/*.csproj"] - një model global, ne mbledhim të gjitha projektet C # nga të gjitha drejtoritë.
metadata.src.exclude: ["*.tests*/**"] - model global, përjashtoni gjithçka nga dosjet me .tests Në titull

Nëntotali

Një konfigurim kaq i thjeshtë mund të krijohet në vetëm gjysmë ore dhe disa filxhanë kafeje, të cilat do t'ju lejojnë të kontrolloni nëse kodi është ndërtuar dhe testet kalojnë, të ndërtoni një paketë të re, të përditësoni dokumentacionin dhe të kënaqni syrin me bukuri. shënjat në README të projektit me çdo kërkesë për bashkim dhe dërgim te masteri.

Përfundimtar .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

Duke folur për distinktivët

Për shkak të tyre, në fund të fundit, gjithçka filloi!

Shenjat me statuset e tubacioneve dhe mbulimin e kodeve janë të disponueshme në GitLab në cilësimet CI/CD në bllokun e tubacioneve Gtntral:

Krijova një distinktiv me një lidhje me dokumentacionin në platformë mburoja.io - gjithçka është mjaft e thjeshtë atje, mund të krijoni distinktivin tuaj dhe ta merrni duke përdorur një kërkesë.

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

Azure DevOps Artifacts ju lejon gjithashtu të krijoni distinktivë për paketat me versionin më të fundit. Për ta bërë këtë, në burimin në faqen Azure DevOps, duhet të klikoni në Krijo distinktivin për paketën e zgjedhur dhe të kopjoni shënimin e shënimit:

Duke shtuar bukurinë

Theksimi i fragmenteve të konfigurimit të zakonshëm

Ndërsa shkruaja konfigurimin dhe kërkoja nëpër dokumentacion, hasa në një veçori interesante të YAML - ripërdorimin e fragmenteve.

Siç mund ta shihni nga cilësimet e detyrës, të gjitha ato kërkojnë etiketën windows në runner, dhe aktivizohen kur një kërkesë për bashkim i dërgohet masterit/krijuar (përveç dokumentacionit). Le ta shtojmë këtë në fragmentin që do të ripërdorim:

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

Dhe tani mund të fusim fragmentin e deklaruar më herët në përshkrimin e detyrës:

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

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

Versionimi i paketës

Kur krijon një paketë, përpiluesi kontrollon çelësat e linjës së komandës, dhe në mungesë të tyre, skedarët e projektit; kur gjen një nyje Versioni, merr vlerën e saj si versioni i paketës që po ndërtohet. Rezulton se për të ndërtuar një paketë me një version të ri, duhet ose ta përditësoni atë në skedarin e projektit ose ta kaloni atë si një argument të linjës së komandës.

Le të shtojmë edhe një listë dëshirash - le që dy numrat e vegjël në version të jenë viti dhe data e krijimit të paketës, dhe shtojmë versionet e lëshimit paraprak. Natyrisht, ju mund t'i shtoni këto të dhëna në skedarin e projektit dhe t'i kontrolloni përpara çdo paraqitjeje - por mund ta bëni gjithashtu në linjë, duke mbledhur versionin e paketës nga konteksti dhe duke e kaluar atë përmes argumentit të linjës së komandës.

Le të biem dakord që nëse mesazhi commit përmban një rresht si release (v./ver./version) <version number> (rev./revision <revision>)?, atëherë do të marrim versionin e paketës nga kjo linjë, do ta plotësojmë me datën aktuale dhe do t'ia kalojmë si argument komandës dotnet pack. Në mungesë të një linje, ne thjesht nuk do ta mbledhim paketën.

Skripti i mëposhtëm zgjidh këtë problem:

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

Shtimi i një skripti në një detyrë pack and deploy job dhe vëzhgoni montimin e paketave në mënyrë rigoroze në prani të një vargu të caktuar në mesazhin commit.

Në total

Pasi kaluam rreth gjysmë ore ose një orë duke shkruar konfigurimin, korrigjimin e gabimeve në powershell-in lokal dhe, ndoshta, disa nisje të pasuksesshme, morëm një konfigurim të thjeshtë për automatizimin e detyrave rutinë.

Sigurisht, GitLab CI / CD është shumë më i gjerë dhe i shumëanshëm sesa mund të duket pas leximit të këtij udhëzuesi - kjo nuk është aspak e vërtetë. Madje atje Auto DevOps ështëduke lejuar

zbulojnë, ndërtojnë, testojnë, vendosin dhe monitorojnë automatikisht aplikacionet tuaja

Tani planet janë për të konfiguruar një tubacion për vendosjen e aplikacioneve në Azure, duke përdorur Pulumi dhe duke përcaktuar automatikisht mjedisin e synuar, i cili do të trajtohet në artikullin vijues.

Burimi: www.habr.com

Një udhëzues për CI/CD në GitLab për fillestarët (pothuajse) absolute