🥇 Leiðbeiningar um CI/CD í GitLab fyrir (næstum) algjöran byrjendur

Eða hvernig á að fá falleg merki fyrir verkefnið þitt á einu kvöldi með auðveldri kóðun

Sennilega klæjar sérhver þróunaraðili sem hefur að minnsta kosti eitt gæludýraverkefni á einhverjum tímapunkti yfir fallegum merkjum með stöðu, kóðaþekju, pakkaútgáfur í nuget ... Og þetta kláði varð til þess að ég skrifaði þessa grein. Sem undirbúningur fyrir að skrifa hana fékk ég þessa fegurð í einu af verkefnum mínum:

Þessi grein mun leiða þig í gegnum grunnuppsetningu stöðugrar samþættingar og afhendingu fyrir .Net Core bekkjarbókasafnsverkefni í GitLab, birta skjöl á GitLab síður og ýta innbyggðum pakka í einkastraum í Azure DevOps.

VS kóða var notað sem þróunarumhverfi með viðbyggingunni GitLab vinnuflæði (til að staðfesta stillingaskrána beint úr þróunarumhverfinu).

Stutt kynning

CD - er það þegar þú ýtir bara, og allt hefur þegar fallið á viðskiptavininn?

Hvað er CI / CD og hvers vegna þú þarft það - þú getur auðveldlega googlað það. Finndu heildar skjöl um að stilla leiðslur í GitLab líka auðvelt. Hér mun ég stuttlega og, ef mögulegt er, án galla lýsa ferli kerfisins frá fuglaskoðun:

verktaki sendir skuldbindingu til geymslunnar, býr til samrunabeiðni í gegnum síðuna, eða á annan hátt, beinlínis eða óbeint ræsir leiðsluna,
öll verkefni eru valin úr uppsetningunni, þar sem skilyrðin gera kleift að ræsa þau í tilteknu samhengi,
verkefni eru skipulögð eftir stigum þeirra,
áfangar eru framkvæmdir til skiptis - þ.e. samhliða öllum verkefnum á þessu stigi er lokið,
ef stigið mistekst (þ.e. að minnsta kosti eitt af verkefnum áfangans mistekst), stöðvast leiðslan (næstum alltaf),
ef öllum áföngum er lokið með góðum árangri telst leiðslan vel heppnuð.

Þannig höfum við:

leiðsla - sett af verkefnum sem eru skipulögð í áföngum þar sem þú getur smíðað, prófað, pakkað kóða, sett fullbúna byggingu í skýjaþjónustu o.s.frv.,
stigi (stigi) — skipulagseining fyrir leiðslur, inniheldur 1+ verkefni,
verkefni (starf) er verkeining í pípunum. Það samanstendur af handriti (skyldubundið), upphafsskilyrðum, stillingum fyrir birtingu/skyndiminni gripi og margt fleira.

Í samræmi við það kemur verkefnið við uppsetningu CI / CD niður á að búa til verkefnasett sem útfærir allar nauðsynlegar aðgerðir til að byggja, prófa og gefa út kóða og gripi.

Áður en byrjað er: hvers vegna?

Af hverju Gitlab?

Vegna þess að þegar það varð nauðsynlegt að búa til einkageymslur fyrir gæludýraverkefni fengu þau borgað á GitHub og ég var gráðugur. Geymslurnar eru orðnar ókeypis, en enn sem komið er er þetta ekki næg ástæða fyrir mig að fara yfir á GitHub.

Af hverju ekki Azure DevOps Pipelines?

Vegna þess að þar er stillingin grunnatriði - þekkingar á skipanalínunni er ekki einu sinni krafist. Samþætting við ytri git veitendur - með nokkrum smellum, innflutningur á SSH lyklum til að senda skuldbindingar í geymsluna - líka, leiðslan er auðveldlega stillt jafnvel ekki frá sniðmáti.

Upphafsstaða: hvað þú hefur og hvað þú vilt

Við höfum:

geymsla í GitLab.

Við viljum:

sjálfvirk samsetning og prófun fyrir hverja samrunabeiðni,
byggja pakka fyrir hverja samrunabeiðni og ýta til skipstjóra, að því tilskildu að það sé ákveðin lína í commit skilaboðunum,
að senda innbyggða pakka í einkastraum í Azure DevOps,
samsetning skjala og birtingar á GitLab síðum,
merki!11

Kröfurnar sem lýst er falla lífrænt undir eftirfarandi leiðslulíkan:

Stig 1 - samsetning
- Við söfnum kóðanum, birtum úttaksskrárnar sem artifacts
Stig 2 - prófun
- Við fáum gripi frá byggingarstigi, keyrum próf, söfnum kóða umfangsgögnum
Stig 3 - Senda inn
- Verkefni 1 - smíðaðu nuget pakkann og sendu hann til Azure DevOps
- Verkefni 2 - við söfnum síðunni frá xmldoc í frumkóðann og birtum hann á GitLab síðum

Byrjum!

Að safna uppsetningunni

Undirbúningur reikninga

Búðu til reikning í Microsoft Azure
Fara til Azure DevOps
Við búum til nýtt verkefni
1. Nafn - hvaða
2. Skyggni - hvaða
Þegar þú smellir á hnappinn Búa til verður verkefnið búið til og þér verður vísað á síðu þess. Á þessari síðu geturðu slökkt á óþarfa eiginleikum með því að fara í verkefnastillingarnar (neðri hlekkur á listanum til vinstri -> Yfirlit -> Azure DevOps Services blokk)
Farðu í Atrifacts, smelltu á Búa til straum
1. Sláðu inn nafn upprunans
2. Veldu sýnileika
3. Taktu hakið af Láttu pakka frá algengum opinberum aðilum fylgja með, svo að uppspretta breytist ekki í dump nuget klón
Smelltu á Tengjast við straum, veldu Visual Studio, afritaðu uppruna úr vélauppsetningarblokkinni
Farðu í reikningsstillingar, veldu Personal Access Token
Búðu til nýjan aðgangslykil
1. Nafn - handahófskennt
2. Skipulag - Núverandi
3. Gildir að hámarki í 1 ár
4. Umfang - Pökkun/Lesa & Skrifa
Afritaðu táknið sem búið var til - eftir að modal glugganum er lokað verður gildið ekki tiltækt
Farðu í geymslustillingarnar í GitLab, veldu CI / CD stillingarnar
Stækkaðu Variables blokkina, bættu við nýjum
1. Nafn - hvaða sem er án bils (verður fáanlegt í skipanaskelinni)
2. Gildi - aðgangslykill úr 9. mgr
3. Veldu Mask breytu

Þetta lýkur forstillingunni.

Undirbúningur stillingaramma

Sjálfgefið er að CI/CD stillingar í GitLab notar skrána .gitlab-ci.yml frá rót geymslunnar. Þú getur stillt handahófskennda slóð að þessari skrá í stillingum geymslunnar, en í þessu tilfelli er það ekki nauðsynlegt.

Eins og þú sérð af viðbótinni inniheldur skráin stillingar á sniðinu YAML. Í skjölunum er greint frá því hvaða lykla er hægt að geyma á efsta stigi stillingarinnar og á hverju hreiðra stigi.

Í fyrsta lagi skulum við bæta við tengil á bryggjumyndina í stillingarskránni, þar sem verkefnin verða framkvæmd. Fyrir þetta finnum við .Net Core myndasíðu á Docker Hub. Í GitHub það er ítarleg leiðarvísir um hvaða mynd á að velja fyrir mismunandi verkefni. Mynd með .Net Core 3.1 hentar okkur að smíða, svo ekki hika við að bæta fyrstu línunni við uppsetninguna

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

Nú, þegar leiðslan er hleypt af stokkunum frá Microsoft myndageymslunni, verður tilgreind mynd hlaðið niður, þar sem öll verkefni úr uppsetningunni verða framkvæmd.

Næsta skref er að bæta við stigi's. Sjálfgefið skilgreinir GitLab 5 stig:

.pre - flutt upp á öllum stigum,
.post - flutt eftir öll stig,
build - fyrst á eftir .pre svið,
test - annar áfangi,
deploy - þriðja stig.

Ekkert kemur í veg fyrir að þú getir lýst þeim skýrt yfir. Röðin sem skrefin eru skráð í hefur áhrif á í hvaða röð þau eru framkvæmd. Til fullnustu skulum við bæta við uppsetninguna:

stages:
  - build
  - test
  - deploy

Fyrir villuleit er skynsamlegt að fá upplýsingar um umhverfið sem verkefnin eru unnin í. Við skulum bæta við alþjóðlegu setti skipana sem verða framkvæmdar fyrir hvert verkefni með before_script:

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

Eftir er að bæta við að minnsta kosti einu verkefni þannig að þegar skuldbindingarnar eru sendar mun leiðslan hefjast. Í bili skulum við bæta við tómu verkefni til að sýna fram á:

dummy job:
  script:
    - echo ok

Við byrjum löggildingu, við fáum skilaboð um að allt sé í lagi, við skuldbindum okkur, við ýtum, skoðum niðurstöðurnar á síðunni ... Og við fáum skriftuvillu - bash: .PSVersion: command not found. wtf?

Allt er rökrétt - sjálfgefið, hlauparar (ábyrgir fyrir framkvæmd verkefnaforskrifta og útvegaðir af GitLab) nota bash til að framkvæma skipanir. Þú getur lagað þetta með því að tilgreina sérstaklega í verkefnalýsingunni hvaða merki keyrandi leiðsluhlaupari ætti að hafa:

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

Frábært! Lögnin er nú í gangi.

Eftirtektarsamur lesandi, eftir að hafa endurtekið tilgreind skref, mun taka eftir því að verkefninu var lokið á sviðinu test, þó við höfum ekki tilgreint sviðið. Eins og þú gætir giska á test er sjálfgefið skref.

Við skulum halda áfram að búa til stillingarbeinagrindina með því að bæta við öllum verkefnum sem lýst er hér að ofan:

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

Við fengum ekki sérlega virka, en engu að síður rétta leiðslu.

Að setja upp kveikjur

Vegna þess að engar kveikjusíur eru tilgreindar fyrir neitt verkefnanna mun leiðslan gera það að fullu vera framkvæmt í hvert sinn sem skuldbindingu er ýtt í geymsluna. Þar sem þetta er ekki æskileg hegðun almennt munum við setja upp kveikjusíur fyrir verkefni.

Hægt er að stilla síur á tveimur sniðum: aðeins/nema и reglur. Í stuttu máli, only/except gerir þér kleift að stilla síur eftir kveikjum (merge_request, til dæmis - stillir verkefnið til að framkvæma í hvert sinn sem pull request er búin til og í hvert skipti sem skuldbindingar eru sendar til útibúsins sem er uppspretta samrunabeiðnarinnar) og útibúsheita (þar á meðal með því að nota regluleg segð); rules gerir þér kleift að sérsníða sett af skilyrðum og, valfrjálst, breyta skilyrðum fyrir framkvæmd verks eftir árangri fyrri verkefna (when í GitLab CI/CD).

Við skulum rifja upp sett af kröfum - samsetningu og prófun eingöngu fyrir samrunabeiðni, pökkun og sendingu til Azure DevOps - fyrir samrunabeiðni og ýtingu til meistara, skjalagerð - fyrir ýtingu til meistara.

Í fyrsta lagi skulum við setja upp kóðasmíðaverkefnið með því að bæta við reglu sem ræsir aðeins við samrunabeiðni:

build job:
  # snip
  only:
    - merge_request

Nú skulum við setja upp umbúðaverkefnið til að skjóta á samrunabeiðnina og bæta skuldbindingum við meistarann:

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

Eins og þú sérð er allt einfalt og einfalt.

Þú getur líka stillt verkefnið þannig að það ræsir aðeins ef sameiningarbeiðni er búin til með tilteknu markmiði eða upprunagrein:

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

Við aðstæður geturðu notað breytur sem taldar eru upp hér; reglum rules ósamrýmanleg reglum only/except.

Stillir vistun artifacts

Meðan á verkefni stendur build job við munum búa til gripi sem hægt er að endurnýta í síðari verkefnum. Til að gera þetta þarftu að bæta slóðum við verkstillingar, skrárnar sem þú þarft að vista og endurnýta í eftirfarandi verkefnum, við lykilinn artifacts:

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

Slóðir styðja jokertákn, sem gerir það örugglega auðveldara að stilla.

Ef verkefni býr til gripi, þá mun hvert síðara verkefni geta fengið aðgang að þeim - þeir verða staðsettir eftir sömu slóðum miðað við geymslurótina sem var safnað úr upprunalega verkefninu. Einnig er hægt að hlaða niður gripum á síðunni.

Nú þegar við erum með uppsetningarramma tilbúinn (og prófaður), getum við haldið áfram að skrifa forskriftir fyrir verkefni.

Við skrifum handrit

Kannski, einu sinni, í vetrarbraut langt, langt í burtu, var það sársauki að byggja verkefni (þar á meðal þau á .net) frá skipanalínunni. Nú geturðu smíðað, prófað og birt verkefnið í 3 teymum:

dotnet build
dotnet test
dotnet pack

Auðvitað eru nokkur blæbrigði sem við munum flækja skipanirnar nokkuð.

Við viljum útgáfuuppbyggingu, ekki kembiforrit, svo við bætum við hverja skipun -c Release
Þegar við prófum viljum við safna kóðaþekjugögnum, svo við þurfum að hafa þekjugreiningartæki í prófunarsöfnunum:
1. Bættu pakkanum við öll prófunarsöfn coverlet.msbuild: dotnet add package coverlet.msbuild úr verkefnamöppu
2. Bættu við prófunarskipunina /p:CollectCoverage=true
3. Bættu lykli við uppsetningu prófunarverkefna til að fá umfjöllunarniðurstöður (sjá hér að neðan)
Þegar kóðanum er pakkað í nuget pakka skaltu stilla úttaksskrána fyrir pakkana: -o .

Söfnun kóða umfangsgagna

Eftir að hafa keyrt prófin prentar Coverlet út keyrslutölfræði á stjórnborðið:

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 gerir þér kleift að tilgreina reglulega tjáningu til að fá tölfræði, sem síðan er hægt að fá í formi merkis. Regluleg tjáning er tilgreind í verkefnastillingunum með lyklinum coverage; tjáningin verður að innihalda handfangahóp, en gildi hans verður sent til merkisins:

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

Hér fáum við tölfræði úr línu með heildarlínuþekju.

Birta pakka og skjöl

Báðar aðgerðir eru áætlaðar á síðasta stigi leiðslunnar - þar sem samsetningin og prófin hafa staðist getum við deilt þróun okkar með heiminum.

Fyrst skaltu íhuga að birta í pakkanum:

Ef verkefnið er ekki með núget stillingarskrá (nuget.config), búðu til nýjan: dotnet new nugetconfig

Til hvers: myndin hefur hugsanlega ekki skrifaðgang að alþjóðlegum (notanda og vél) stillingum. Til að ná ekki villum búum við einfaldlega til nýja staðbundna uppsetningu og vinnum með hana.
Við skulum bæta nýjum pakkagjafa við staðbundna uppsetningu: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - heiti staðbundins uppruna, ekki mikilvægt
2. url - Vefslóð heimildarinnar frá stiginu „Undirbúningur reikninga“, bls. 6
3. organization - nafn fyrirtækis í Azure DevOps
4. gitlab variable - heiti breytunnar með aðgangslyklinum bætt við GitLab ("Undirbúningur reikninga", bls. 11). Auðvitað, í formi $variableName
5. -StorePasswordInClearText - hakk til að komast framhjá villunni sem hafnað var aðgangi (Ég er ekki sá fyrsti sem stígur á þessa hrífu)
6. Ef um villur er að ræða getur verið gagnlegt að bæta við -verbosity detailed
Að senda pakkann til upprunans: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Við sendum alla pakka úr núverandi skrá, svo *.nupkg.
2. name - frá skrefinu að ofan.
3. key - hvaða línu sem er. Í Azure DevOps, í Connect to feed glugganum, er dæmið alltaf línan az.
4. -skipduplicate - þegar reynt er að senda pakka sem þegar er til án þessa lykils mun uppsprettan skila villu 409 Conflict; með lyklinum verður sendingu sleppt.

Nú skulum við setja upp gerð skjala:

Í fyrsta lagi, í geymslunni, í aðalútibúinu, frumstillum við docfx verkefnið. Til að gera þetta skaltu keyra skipunina frá rótinni docfx init og stilltu gagnvirkt lykilfæribreytur fyrir byggingarskjöl. Ítarleg lýsing á lágmarksverkefnisuppsetningu hér.
1. Við uppsetningu er mikilvægt að tilgreina úttaksskrána ..public - GitLab tekur sjálfgefið innihald opinberu möppunnar í rót geymslunnar sem uppsprettu fyrir Pages. Vegna þess að verkefnið verður staðsett í möppu sem er hreiður í geymslunni - bættu útlagi við stigið upp í slóðinni.
Við skulum ýta á breytingarnar á GitLab.
Bættu verkefni við leiðslustillingu pages (áskilið orð fyrir útgáfuverkefni á GitLab síðum):
1. Handrit:
  1. nuget install docfx.console -version 2.51.0 - setja upp docfx; útgáfan er tilgreind til að tryggja að uppsetningarleiðir pakkans séu réttar.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - safna skjölum
2. Hnútargripir:

pages:
  # snip
  artifacts:
    paths:
      - public

Ljóðræn útrás um docfx

Áður, þegar ég setti upp verkefni, tilgreindi ég kóðann fyrir skjölin sem lausnarskrá. Helsti ókosturinn er að skjöl eru einnig búin til fyrir prófunarverkefni. Ef þetta er ekki nauðsynlegt geturðu stillt þetta gildi á hnútinn metadata.src:

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

metadata.src.src: "../" - við förum einu stigi upp miðað við staðsetningu docfx.json, vegna þess í mynstrum virkar ekki að leita í skráartrénu.
metadata.src.files: ["**/*.csproj"] - alþjóðlegt mynstur, við söfnum öllum C # verkefnum úr öllum möppum.
metadata.src.exclude: ["*.tests*/**"] - alþjóðlegt mynstur, útilokaðu allt úr möppum með .tests Í titlinum

Samtals

Svo einfalda uppsetningu er hægt að búa til á aðeins hálftíma og nokkra bolla af kaffi, sem gerir þér kleift að athuga hvort kóðinn sé smíðaður og prófin standist, smíða nýjan pakka, uppfæra skjölin og gleðja augað með fallegum merki í README verkefnisins með hverri sameiningarbeiðni og sendingu til skipstjóra.

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

Talandi um merki

Vegna þeirra var þegar allt kom til alls byrjað!

Merki með leiðslustöðu og kóðaþekju eru fáanleg í GitLab í CI/CD stillingum í Gtntral leiðslublokkinni:

Ég bjó til merki með tengli á skjölin á pallinum shields.io - þar er allt frekar einfalt, þú getur búið til þitt eigið merki og fengið það með beiðni.

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

Azure DevOps Artifacts gerir þér einnig kleift að búa til merki fyrir pakka með nýjustu útgáfunni. Til að gera þetta, í upprunanum á Azure DevOps síðunni, þarftu að smella á Búa til merki fyrir valinn pakka og afrita merkinguna:

Að bæta við fegurð

Auðkenndu algengar stillingarbrot

Þegar ég skrifaði uppsetninguna og leitaði í gegnum skjölin rakst ég á áhugaverðan eiginleika YAML - endurnotkun brota.

Eins og þú sérð af verkefnastillingunum þurfa þær allar merkið windows hjá hlauparanum og koma af stað þegar sameiningarbeiðni er send til skipstjóra/stofnað (nema skjöl). Við skulum bæta þessu við brotið sem við munum endurnýta:

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

Og nú getum við sett brotið sem lýst var yfir fyrr í verkefnalýsingunni:

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

Brotaheiti verða að byrja á punkti, svo að þau séu ekki túlkuð sem verkefni.

Útgáfa pakka

Þegar pakka er búinn til athugar þýðandinn skipanalínurofana og ef þeir eru ekki til, verkefnaskrárnar; þegar það finnur útgáfuhnút tekur það gildi sitt sem útgáfu pakkans sem verið er að smíða. Það kemur í ljós að til að búa til pakka með nýrri útgáfu þarftu annað hvort að uppfæra hann í verkefnaskránni eða senda hann sem skipanalínurök.

Bætum við einni óskalista í viðbót - látum litlu tölurnar tvær í útgáfunni vera ártal og byggingardagsetningu pakkans og bætum við forútgáfuútgáfum. Auðvitað geturðu bætt þessum gögnum við verkefnisskrána og athugað fyrir hverja sendingu - en þú getur líka gert það í leiðslunni, safnað pakkaútgáfunni úr samhenginu og komið því í gegnum skipanalínurök.

Við skulum vera sammála um að ef commit skilaboðin innihalda línu eins release (v./ver./version) <version number> (rev./revision <revision>)?, þá munum við taka útgáfuna af pakkanum af þessari línu, bæta því við núverandi dagsetningu og senda það sem rök til skipunarinnar dotnet pack. Ef lína er ekki til munum við einfaldlega ekki sækja pakkann.

Eftirfarandi handrit leysir þetta vandamál:

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

Að bæta handriti við verkefni pack and deploy job og fylgdu samsetningu pakka nákvæmlega í viðurvist ákveðins strengs í commit skilaboðunum.

Alls

Eftir að hafa eytt um hálftíma eða klukkutíma í að skrifa uppsetninguna, kemba í staðbundinni powershell og hugsanlega nokkrum misheppnuðum ræsingum, fengum við einfalda uppsetningu fyrir sjálfvirkan venjubundin verkefni.

Auðvitað er GitLab CI / CD miklu umfangsmeiri og margþættari en það kann að virðast eftir að hafa lesið þessa handbók - það er alls ekki satt. Þar jafnvel Auto DevOps erleyfa

greina, smíða, prófa, dreifa og fylgjast með forritunum þínum sjálfkrafa

Nú eru áformin að stilla leiðslu til að dreifa forritum í Azure, nota Pulumi og sjálfkrafa ákvarða markumhverfið, sem fjallað verður um í næstu grein.

Heimild: www.habr.com

Leiðbeiningar um CI/CD í GitLab fyrir (næstum) algjöran byrjendur