🥇GitLab-en CI/CDrako gida (ia) erabateko hasiberrientzat

Edo nola lortu zure proiekturako txapa ederrak kodetze errazeko arratsalde batean

Seguruenik, uneren batean gutxienez maskota-proiektu bat duen garatzaile bakoitzak egoera, kode estaldura, paketeen bertsioak nuget-eko txapa ederrei buruzko azkura daukate... Eta azkura horrek eraman ninduen artikulu hau idaztera. Idazteko prestatzeko, edertasun hau lortu nuen nire proiektuetako batean:

Artikulu honek GitLab-en .Net Core klaseko liburutegi-proiektu baterako etengabeko integrazioaren eta entregaren oinarrizko konfigurazioan zehar gidatuko zaitu, GitLab Pages-en dokumentazioa argitaratuz eta eraikitako paketeak Azure DevOps-en jario pribatu batera bultzatuz.

VS Code garapen-ingurune gisa erabili zen luzapenarekin GitLab lan-fluxua (ezarpen fitxategia garapen ingurunetik zuzenean balioztatzeko).

Sarrera laburra

CDa - bultza egin duzunean eta dena dagoeneko bezeroaren gainean erori da?

Zer da CI / CD eta zergatik behar duzun - erraz Googlen bila dezakezu. Bilatu GitLab-en kanalizazioak konfiguratzeko dokumentazio osoa erraza ere. Hemen laburki eta, ahal bada, akatsik gabe deskribatuko dut sistemaren prozesua txori ikuspegitik:

garatzaileak konpromezu bat bidaltzen du biltegira, bateratze-eskaera bat sortzen du gunearen bidez, edo beste modu batean, esplizituki edo inplizituki kanalizazioa abiarazten du,
ataza guztiak konfiguraziotik hautatzen dira, eta horren baldintzek emandako testuinguruan abiarazteko aukera ematen dute,
zereginak beren faseen arabera antolatzen dira,
etapak txandaka exekutatzen dira - hau da. paraleloa etapa honetako zeregin guztiak amaituta daude,
etapak huts egiten badu (hau da, etapako zereginetako batek gutxienez huts egiten badu), kanalizazioa gelditzen da (ia beti),
fase guztiak arrakastaz betetzen badira, kanalizazioa arrakastatsutzat jotzen da.

Horrela, honako hauek ditugu:

kanalizazioa - fasetan antolatutako ataza multzoa, zeinetan eraiki, probatu, kodea paketatu, amaitutako eraikuntza bat hodeiko zerbitzu batean zabaldu dezakezun, etab.,
etapa (etapa) — kanalizazioaren antolamendu-unitatea, 1+ ataza dauka,
zeregina (lan) kanalizazioan dagoen lan-unitatea da. Script bat (derrigorrezkoa), abiarazte-baldintzek, artefaktuak argitaratzeko/cacheatzeko ezarpenak eta askoz gehiago ditu.

Horren arabera, CI / CDa konfiguratzean zeregina kodea eta artefaktuak eraikitzeko, probatzeko eta argitaratzeko beharrezko ekintza guztiak ezartzen dituen ataza multzo bat sortzea da.

Hasi aurretik: zergatik?

Zergatik Gitlab?

Maskoten proiektuetarako biltegi pribatuak sortzea beharrezkoa izan zenean, GitHub-en ordaintzen baitzituzten, eta gutizia nengoen. Biltegiak aske bihurtu dira, baina orain arte hau ez da nahikoa arrazoi GitHubera mugitzeko.

Zergatik ez Azure DevOps Pipelines?

Hor ezarpena oinarrizkoa delako - komando-lerroaren ezagutza ere ez da beharrezkoa. Kanpoko git hornitzaileekin integratzea - klik pare batean, SSH gakoak inportatu biltegira konpromezuak bidaltzeko - ere, kanalizazioa erraz konfiguratzen da txantiloi batetik ez bada ere.

Hasierako posizioa: zer duzun eta zer nahi duzun

Daukagu:

biltegia GitLab-en.

Nahi dugu:

batuketa eskaera bakoitzerako muntaketa eta proba automatikoak,
bateratze-eskaera bakoitzerako paketeak eraikitzea eta maisuari bultzatzea, betiere konpromiso-mezuan lerro jakin bat badago,
eraikitako paketeak Azure DevOps-en jario pribatu batera bidaltzea,
dokumentazioaren muntaketa eta argitalpena GitLab orrialdeetan,
txapak!11

Deskribatutako eskakizunak organikoki honako kanalizazio-eredu honetan daude:

1. etapa - muntaia
- Kodea biltzen dugu, irteerako fitxategiak artefaktu gisa argitaratzen ditugu
2. etapa - proba
- Eraikitze fasetik artefaktuak lortzen ditugu, probak exekutatzen ditugu, kodearen estaldura datuak biltzen ditugu
3. etapa - Bidali
- 1. ataza: eraiki nuget paketea eta bidali Azure DevOps-era
- 2. ataza - gunea xmldoc-etik jasotzen dugu iturburu-kodean eta GitLab orrialdeetan argitaratzen dugu

Has gaitezen!

Konfigurazioa biltzea

Kontuak prestatzea

Sortu kontu bat hemen Microsoft Azure
Joan Azure DevOps
Proiektu berri bat sortzen dugu
1. Izena - edozein
2. Ikusgarritasuna - edozein
Sortu botoian klik egiten duzunean, proiektua sortuko da eta bere orrialdera birbideratuko zara. Orri honetan, beharrezkoak ez diren funtzioak desgai ditzakezu proiektuaren ezarpenetara joanez (ezkerreko zerrendako beheko esteka -> Ikuspegi orokorra -> Azure DevOps Zerbitzuen blokea)
Joan Atrifacts atalera, egin klik Sortu jarioa
1. Sartu iturriaren izena
2. Aukeratu ikusgarritasuna
3. Desmarkatu Sartu iturri publiko arruntetako paketeak, iturria dump nuget klon bihur ez dadin
Sakatu Konektatu jariorako, hautatu Visual Studio, kopiatu Iturria Makina konfigurazio bloketik
Joan kontuaren ezarpenetara, hautatu Sarbide Token pertsonala
Sortu sarbide-token berri bat
1. Izena - arbitrarioa
2. Antolaketa - egungoa
3. Gehienez urtebeterako balio du
4. Eremua - Paketatzea/Irakurri eta idatzi
Kopiatu sortutako tokena - leiho modala itxi ondoren, balioa ez da erabilgarri egongo
Joan GitLab-eko biltegiaren ezarpenetara, hautatu CI / CD ezarpenak
Zabaldu Aldagaiak blokea, gehitu berri bat
1. Izena - zuriunerik gabeko edozein (komando shellean egongo da eskuragarri)
2. Balioa - 9. paragrafoko sarbide-tokena
3. Hautatu Maskara aldagaia

Honek aurrekonfigurazioa osatzen du.

Konfigurazio-esparrua prestatzea

Lehenespenez, GitLab-eko CI/CD konfigurazioak fitxategia erabiltzen du .gitlab-ci.yml biltegiaren errotik. Fitxategi honetarako bide arbitrario bat ezar dezakezu biltegiaren ezarpenetan, baina kasu honetan ez da beharrezkoa.

Luzapenean ikus dezakezun bezala, fitxategiak formatuan konfigurazio bat dauka YAML. Dokumentazioak zehazten du zein gako egon daitezkeen konfigurazioaren goiko mailan eta habiaraturiko maila bakoitzean.

Lehenik eta behin, gehi diezaiogun esteka bat docker irudiari konfigurazio fitxategian, eta bertan egingo diren zereginak. Horretarako aurkitzen dugu .Net Core irudien orria Docker Hub-en. Urtean GitHub zeregin desberdinetarako zein irudi aukeratu behar den gida zehatza dago. .Net Core 3.1-ekin irudi bat eraikitzeko egokia da, beraz, anima zaitez lehen lerroa gehitzeko konfigurazioari

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

Orain, kanalizazioa Microsoft-eko irudi biltegitik abiarazten denean, zehaztutako irudia deskargatuko da, eta bertan konfigurazioko zeregin guztiak exekutatu egingo dira.

Hurrengo urratsa gehitzea da etapa's. Lehenespenez, GitLab-ek 5 etapa definitzen ditu:

.pre - etapa guztietara arte egina,
.post - etapa guztien ondoren antzeztua,
build - lehenengo ondoren .pre etapa,
test - Bigarren fasea,
deploy - Hirugarren etapa.

Ezerk ez dizu eragozten esplizituki deklaratzea, ordea. Urratsak zerrendatzen diren ordenak egiten diren ordenari eragiten dio. Osatzeko, gehitu diezaiogun konfigurazioari:

stages:
  - build
  - test
  - deploy

Arazketarako, zentzuzkoa da zereginak exekutatzen diren inguruneari buruzko informazioa jasotzea. Gehitu dezagun zeregin bakoitzaren aurretik exekutatuko diren komando multzo global bat before_script:

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

Gutxienez zeregin bat gehitzea geratzen da, konpromezuak bidaltzen direnean kanalizazioa abiarazteko. Oraingoz, gehi dezagun zeregin huts bat frogatzeko:

dummy job:
  script:
    - echo ok

Balioztatzea hasten dugu, dena ondo dagoela dioen mezua jasotzen dugu, konpromisoa hartzen dugu, bultzatzen dugu, gunean emaitzak ikusten ditugu ... Eta script errore bat jasotzen dugu - bash: .PSVersion: command not found. wtf?

Dena logikoa da; lehenespenez, korrikalariek (zereginen script-ak exekutatzeko arduradunak eta GitLab-ek emandakoak) erabiltzen dituzte. bash komandoak exekutatzeko. Hau konpon dezakezu zereginaren deskribapenean espresuki zehaztuz zein etiketa izan behar dituen exekutatzen ari den kanalizazioaren korrikalariak:

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

Bikaina! Hodibidea martxan da orain.

Irakurle adi batek, adierazitako pausoak errepikatu ondoren, ataza fasean amaitu dela ohartuko da test, etapa zehaztu ez dugun arren. Asma dezakezun bezala test urrats lehenetsia da.

Jarrai dezagun konfigurazio hezurdura sortzen goian deskribatutako zeregin guztiak gehituz:

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

Ez bereziki funtzionala, baina zuzena den kanalizazioa lortu dugu.

Abiarazleak konfiguratzea

Zereginetako inongo abiarazle-iragazkirik zehazten ez denez, kanalizazioak egingo du guztiz exekutatu egingo da konpromiso bat biltegira bultzatzen den bakoitzean. Orokorrean nahi den jokabidea ez denez, atazetarako abiarazte-iragazkiak ezarriko ditugu.

Iragazkiak bi formatutan konfigura daitezke: bakarrik/salbu и arauak. Laburbilduz, only/except abiarazleen arabera iragazkiak konfiguratzeko aukera ematen du (merge_request, adibidez - tira-eskaera bat sortzen den bakoitzean eta konpromisoak bidaltzen diren bakoitzean bateratze-eskaeran iturria den adarrera) eta adar-izenak ezartzen ditu (esamolde erregularrak erabiliz barne); rules Baldintza multzo bat pertsonalizatzeko aukera ematen du eta, aukeran, zereginen exekuzio-baldintza aldatzeko, aurreko zereginen arrakastaren arabera (when GitLab CI/CD-n).

Gogora ditzagun baldintza multzo bat - muntaketa eta probak bateratze-eskaera, ontziratzea eta Azure DevOps-era bidaltzeko soilik - bateratze-eskaera eta masterra bultzatzeko, dokumentazioa sortzeko - maisurako bultzadarako.

Lehenik eta behin, konfigura dezagun kodea sortzeko zeregina bateratze-eskaeran soilik abiarazten den arau bat gehituz:

build job:
  # snip
  only:
    - merge_request

Orain konfigura dezagun ontziratzeko zeregina bateratze-eskaeran abiarazteko eta konpromezuak gehitzeko maisuari:

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

Ikusten duzun bezala, dena sinplea eta zuzena da.

Ere ezar dezakezu zeregina abiarazteko soilik helburu edo iturburu adar jakin batekin bateratze-eskaera bat sortzen bada:

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

Baldintzetan, erabil dezakezu hemen zerrendatutako aldagaiak; arauak rules arauekin bateraezina only/except.

Artifact gordetzea konfiguratzea

Zeregin batean zehar build job hurrengo lanetan berrerabili daitezkeen artefaktuak eraikiko ditugu. Horretarako, ataza-konfiguraziorako bideak gehitu behar dituzu, hurrengo zereginetan gorde eta berrerabili beharko dituzun fitxategiak, teklara. artifacts:

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

Bideek komodinak onartzen dituzte, eta horrek ezartzea errazten du zalantzarik gabe.

Zeregin batek artefaktuak sortzen baditu, ondorengo zeregin bakoitzak haietara sartzeko aukera izango du - jatorrizko atazatik bildutako biltegiaren erroarekiko bide berdinetan kokatuko dira. Artefaktuak ere deskargatu daitezke webgunean.

Orain konfigurazio-esparru bat prest (eta probatu) dugula, zereginetarako script-ak idazten jarraitu dezakegu.

Gidoiak idazten ditugu

Beharbada, garai batean, urrun, urruneko galaxia batean, komando lerrotik proiektuak eraikitzea (.net-ekoa barne) mina zen. Orain proiektua 3 taldetan eraiki, probatu eta argitaratu dezakezu:

dotnet build
dotnet test
dotnet pack

Jakina, badira zenbait ñabardura, eta horregatik komandoak zertxobait zailduko ditugu.

Oharra eraikitze bat nahi dugu, ez arazketa eraikitze bat, beraz komando bakoitzari gehitzen diogu -c Release
Probak egiterakoan, kode-estalduraren datuak bildu nahi ditugu, beraz, estaldura-analizzatzaile bat sartu behar dugu proba-liburutegietan:
1. Gehitu paketea probako liburutegi guztietan coverlet.msbuild: dotnet add package coverlet.msbuild proiektuaren karpetatik
2. Gehitu proba exekutatzeko komandoari /p:CollectCoverage=true
3. Gehitu gako bat proba-zereginaren konfigurazioan estaldura-emaitzak lortzeko (ikus behean)
Kodea nuget paketeetan paketatzean, ezarri paketeen irteerako direktorioa: -o .

Kodearen estalduraren datuak biltzea

Probak exekutatu ondoren, Coverlet inprimatzeek estatistikak exekutatzen dituzte kontsolara:

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-ek adierazpen erregular bat zehaztea ahalbidetzen du estatistikak lortzeko, eta gero txapa moduan lor daitezke. Adierazpen erregularra zereginaren ezarpenetan zehazten da teklarekin coverage; esamoldeak harrapaketa-talde bat izan behar du, eta horren balioa bereizgarrira pasatuko da:

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

Hemen lerroaren estaldura osoa duen lerro baten estatistikak lortzen ditugu.

Paketeak eta dokumentazioa argitaratu

Bi ekintzak kanalizazioaren azken faserako aurreikusita daude: muntaia eta probak gainditu direnez, gure garapenak munduarekin parteka ditzakegu.

Lehenik eta behin, kontuan hartu paketeen iturburuan argitaratzea:

Proiektuak nuget konfigurazio fitxategirik ez badu (nuget.config), sortu berri bat: dotnet new nugetconfig

Zertarako: baliteke irudiak ez izatea konfigurazio globaletarako (erabiltzailea eta makina) idazteko sarbiderik. Akatsak ez harrapatzeko, tokiko konfigurazio berri bat sortu eta harekin lan egiten dugu.
Gehitu dezagun pakete-iturburu berri bat konfigurazio lokalean: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - tokiko iturriaren izena, ez da kritikoa
2. url - "Kontuak prestatzen" etapako iturriaren URLa, 6. or
3. organization - Erakundearen izena Azure DevOps-en
4. gitlab variable - GitLab-era sarbide-tokena duen aldagaiaren izena ("Kontuak prestatzen", 11. or.). Berez, formatuan $variableName
5. -StorePasswordInClearText - ukatutako sarbidea saihesteko hack bat (Ez naiz arrasto hau zapaltzen lehena)
6. Akatsak izanez gero, gehitzea erabilgarria izan daiteke -verbosity detailed
Paketea iturrira bidaltzea: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Pakete guztiak uneko direktoriotik bidaltzen ditugu, beraz *.nupkg.
2. name - goiko urratsetik.
3. key - edozein lerro. Azure DevOps-en, Connect to feed leihoan, adibidea lerroa da beti az.
4. -skipduplicate - Lehendik dagoen pakete bat gako hori gabe bidaltzen saiatzean, iturburuak errore bat itzuliko du 409 Conflict; giltzarekin, bidalketa saltatu egingo da.

Orain konfigura dezagun dokumentazioaren sorrera:

Lehenik eta behin, biltegian, adar maisuan, docfx proiektua abiarazten dugu. Horretarako, exekutatu komandoa errotik docfx init eta interaktiboki ezarri eraikinaren dokumentaziorako funtsezko parametroak. Proiektuaren gutxieneko konfigurazioaren deskribapen zehatza Hemen.
1. Konfiguratzean, garrantzitsua da irteerako direktorioa zehaztea ..public - GitLab-ek lehenespenez biltegiaren erroko karpeta publikoaren edukia hartzen du Pages-en iturri gisa. Zeren proiektua biltegian habiaratuta dagoen karpeta batean kokatuko da - gehitu irteera bat bidean gorako mailara.
Bultza ditzagun GitLab-en aldaketak.
Gehitu zeregin bat kanalizazio-konfigurazioan pages (GitLab orrialdeetan webguneak argitaratzeko zereginetarako gordetako hitza):
1. Gidoia:
  1. nuget install docfx.console -version 2.51.0 - instalatu docfx; bertsioa zehazten da paketeen instalazio-bideak zuzenak direla ziurtatzeko.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - Dokumentazioa biltzea
2. Nodoen artefaktuak:

pages:
  # snip
  artifacts:
    paths:
      - public

Docfx-i buruzko digresio lirikoa

Aurretik, proiektu bat konfiguratzean, dokumentazioaren kode-iturburua zehaztu nuen irtenbide fitxategi gisa. Desabantaila nagusia proba-proiektuetarako dokumentazioa ere sortzen dela da. Hau beharrezkoa ez bada, balio hori ezar dezakezu nodoan metadata.src:

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

metadata.src.src: "../" - Kokapenarekiko maila bat gora egiten dugu docfx.json, zeren ereduetan, direktorioen zuhaitzean bilaketak ez du funtzionatzen.
metadata.src.files: ["**/*.csproj"] - Eredu globala, direktorio guztietako C # proiektu guztiak biltzen ditugu.
metadata.src.exclude: ["*.tests*/**"] - eredu globala, baztertu karpetetatik dena .tests Izenburuan

Subtotala

Horrelako konfigurazio sinple bat ordu erdi eta kafe pare bat edalontzitan sor daiteke, eta horri esker, kodea eraikita dagoela eta probak gainditzen direla egiaztatzeko, pakete berri bat eraiki, dokumentazioa eguneratu eta begia ederrez gozatu ahal izango duzu. txapak proiektuaren README-n bateratze-eskaera bakoitzarekin eta maisuari bidaltzea.

Azken .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

Txapak hitz egitean

Horiengatik, azken finean, dena hasi zen!

Kanalizazio-egoerak eta kodea estaldura duten bereizgarriak GitLab-en eskuragarri daude Gtntral kanalizazio blokeko CI/CD ezarpenetan:

Plataformako dokumentaziorako esteka duen txapa bat sortu dut Shields.io - Dena nahiko erraza da bertan, zure bereizgarria sor dezakezu eta eskaera baten bidez jaso dezakezu.

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

Azure DevOps Artifacts-ek azken bertsioa duten paketeentzako txapak sortzeko aukera ematen du. Horretarako, Azure DevOps guneko iturburuan, hautatutako paketerako Sortu bereizgarria sakatu eta marka-marka kopiatu behar duzu:

Edertasuna gehitzea

Konfigurazio-zati komunak nabarmentzea

Konfigurazioa idazten eta dokumentazioan bilatzean, YAMLren ezaugarri interesgarri batekin egin nuen topo: zatiak berrerabiltzea.

Zereginen ezarpenetan ikus dezakezunez, guztiek behar dute etiketa windows korrikalarian, eta bateratze-eskaera bat maisuari/sortutakoari bidaltzen zaionean abiarazten dira (dokumentazioa izan ezik). Gehi diezaiogun hau berrerabiliko dugun zatiari:

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

Eta orain ataza deskribapenean lehenago deklaratutako zatia txerta dezakegu:

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

Zati-izenak puntu batez hasi behar dira, zeregin gisa interpretatu ez daitezen.

Paketeen bertsioa

Pakete bat sortzean, konpilatzaileak komando-lerroko etengailuak egiaztatzen ditu, eta haiek ezean, proiektuaren fitxategiak; Bertsio-nodo bat aurkitzen duenean, eraikitzen ari den paketearen bertsio gisa hartzen du bere balioa. Ematen du bertsio berri batekin pakete bat eraikitzeko, proiektuaren fitxategian eguneratu edo komando lerroko argumentu gisa pasa behar duzula.

Gehitu dezagun nahi-zerrenda bat gehiago: utzi bertsioko bi zenbaki txikiak paketearen urtea eta eraikitze-data izan, eta gehitu aurreko bertsioak. Jakina, datu hauek proiektuaren fitxategira gehi ditzakezu eta bidali aurretik egiaztatu, baina kanalizazioan ere egin dezakezu, paketearen bertsioa testuingurutik bildu eta komando lerroko argumentutik pasatuz.

Onar dezagun konpromisoa mezuak bezalako lerro bat badu release (v./ver./version) <version number> (rev./revision <revision>)?, orduan paketearen bertsioa lerro honetatik hartuko dugu, uneko datarekin osatuko dugu eta komandoari argumentu gisa pasako diogu dotnet pack. Lerrorik ezean, ez dugu paketea bilduko.

Ondorengo script-ak arazo hau konpontzen du:

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

Zeregin bati script bat gehitzea pack and deploy job eta behatu paketeen muntaia zorrotz konprometitutako mezuan kate jakin baten aurrean.

Guztira

Ordu erdi edo ordu bat inguru konfigurazioa idazten, tokiko powershell-en arazketan eta, agian, arrakastarik gabeko abian jarri ondoren, ohiko zereginak automatizatzeko konfigurazio sinple bat lortu genuen.

Jakina, GitLab CI / CD gida hau irakurri ondoren badirudi baino askoz zabalagoa eta anitzagoa da - hori ez da batere egia. Han ere Auto DevOps daahalbidetuz

automatikoki detektatu, eraiki, probatu, zabaldu eta kontrolatu zure aplikazioak

Orain planak Azure-ra aplikazioak zabaltzeko kanalizazio bat konfiguratzea da, Pulumi erabiliz eta helburu-ingurunea automatikoki zehaztuz, hurrengo artikuluan azalduko dena.

Iturria: www.habr.com

GitLab-en CI/CDrako gida (ia) erabateko hasiberrientzat