In gids foar CI / CD yn GitLab foar de (hast) absolute begjinner

Of hoe jo prachtige badges krije foar jo projekt yn ien jûn fan maklike kodearring

Wierskynlik hat elke ûntwikkelder dy't op in stuit op syn minst ien pet-projekt hat in jeuk oer prachtige badges mei statussen, koadedekking, pakketferzjes yn nuget ... En dizze jeuk hat my laat om dit artikel te skriuwen. As tarieding op it skriuwen krige ik dizze skientme yn ien fan myn projekten:

Dit artikel sil liede jo troch de basis opset fan trochgeande yntegraasje en levering foar in .Net Core klasse biblioteek projekt yn GitLab, publisearjen fan dokumintaasje nei GitLab Pages, en triuwe boud pakketten nei in privee feed yn Azure DevOps.

VS Code waard brûkt as de ûntwikkeling omjouwing mei de útwreiding GitLab Workflow (foar it falidearjen fan it ynstellingsbestân direkt fan 'e ûntwikkelingsomjouwing).

Koarte ynlieding

CD - is it as jo gewoan triuwe, en alles is al fallen op 'e klant?

Wat is CI / CD en wêrom jo it nedich hawwe - jo kinne it maklik googleje. Fyn folsleine dokumintaasje oer it konfigurearjen fan pipelines yn GitLab ek maklik. Hjir sil ik koart en, as it mooglik is, sûnder gebreken it proses fan it systeem beskriuwe út in fûgelperspektyf:

• de ûntwikkelder stjoert in commit nei it repository, makket in fúzjefersyk fia de side, of op in oare manier, eksplisyt of ymplisyt de pipeline begjint,
• alle taken wurde selektearre út 'e konfiguraasje, wêrfan de betingsten kinne wurde lansearre yn' e opjûne kontekst,
• taken wurde organisearre neffens har stadia,
• stadia wurde útfierd om beurt - i.e. parallel alle taken fan dit stadium binne foltôge,
• as it poadium mislearret (d.w.s. op syn minst ien fan 'e taken fan it poadium mislearret), stopt de pipeline (hast altyd),
• as alle stadia mei sukses foltôge binne, wurdt de pipeline as suksesfol beskôge.

Sa hawwe wy:

• pipeline - in set fan taken organisearre yn stadia wêryn jo kinne bouwe, testen, pakket koade, ynsette in klear build nei in wolk tsjinst, ensfh
• poadium (toaniel) - pipeline organisaasje ienheid, befettet 1+ taak,
• taak (taak) is in ienheid fan wurk yn 'e pipeline. It bestiet út in skript (ferplicht), startbetingsten, ynstellings foar publisearjen / caching artefakten, en folle mear.

Dêrtroch komt de taak by it ynstellen fan CI / CD del op it meitsjen fan in set fan taken dy't alle nedige aksjes útfiere foar it bouwen, testen en publisearjen fan koade en artefakten.

Foardat jo begjinne: wêrom?

• Wêrom Gitlab?

Want doe't it nedich waard om privee repositories te meitsjen foar húsdierprojekten, waarden se betelle op GitHub, en ik wie gierig. De repositories binne fergees wurden, mar oant no ta is dit net genôch reden foar my om te ferhúzjen nei GitHub.

• Wêrom net Azure DevOps Pipelines?

Om't dêr de ynstelling elemintêr is - kennis fan 'e kommandorigel is net iens fereaske. Yntegraasje mei eksterne git-providers - yn in pear klikken, ymportearje fan SSH-kaaien om commits nei it repository te stjoeren - ek is de pipeline maklik konfigureare, sels net fan in sjabloan.

Startposysje: wat jo hawwe en wat jo wolle

Wy hawwe:

• repository yn GitLab.

Wy wolle:

• automatyske gearstalling en testen foar elk fúzjefersyk,
• it bouwen fan pakketten foar elk fúzjefersyk en triuwe nei de master, op betingst dat d'r in bepaalde rigel is yn it commit-berjocht,
• it ferstjoeren fan boude pakketten nei in privee feed yn Azure DevOps,
• gearstalling fan dokumintaasje en publikaasje yn GitLab-siden,
• kentekens!11

De beskreaune easken falle organysk op it folgjende pipelinemodel:

• Fase 1 - Gearstalling
  • Wy sammelje de koade, publisearje de útfierbestannen as artefakten
• Fase 2 - testen
  • Wy krije artefakten út it boustadium, rinne tests, sammelje koadedekkingsgegevens
• Fase 3 - Yntsjinje
  • Taak 1 - bou it nuget-pakket en stjoer it nei Azure DevOps
  • Taak 2 - wy sammelje de side fan xmldoc yn 'e boarnekoade en publisearje it yn GitLab-siden

Litte wy begjinne!

It sammeljen fan de konfiguraasje

It tarieden fan akkounts

1. Meitsje in akkount yn Microsoft Azure

2. Gean nei Azure DevOps

3. Wy meitsje in nij projekt

   1. Namme - elk
   2. Sichtberens - elk
      

4. As jo ​​op de knop Meitsje klikke, sil it projekt oanmakke wurde en jo wurde omlaat nei de side. Op dizze side kinne jo ûnnedige funksjes útskeakelje troch nei de projektynstellingen te gean (legere keppeling yn 'e list links -> Oersjoch -> Azure DevOps Services-blok)
   

5. Gean nei Atrifacts, klik Feed oanmeitsje

   1. Fier de namme fan 'e boarne yn
   2. Kies sichtberens
   3. Uncheck Pakjes opnimme fan mienskiplike publike boarnen, sadat de boarne net feroaret yn in dump nuget clone
      

6. Klikje Ferbine mei feed, selektearje Visual Studio, kopiearje Boarne fan it blok Masine-opset
   

7. Gean nei akkount ynstellings, selektearje Personal Access Token
   

8. Meitsje in nij tagongstoken

   1. Namme - willekeurich
   2. Organisaasje - aktueel
   3. Jildich foar maksimaal 1 jier
   4. Berik - Ferpakking / Lêze en skriuwe
      

9. Kopiearje it oanmakke token - neidat it modale finster is sletten, sil de wearde net beskikber wêze

10. Gean nei de repository ynstellings yn GitLab, selektearje de CI / CD ynstellings
    

11. Wreidzje it Variables-blok út, foegje in nij ta

    1. Namme - elk sûnder spaasjes (sil beskikber wêze yn 'e kommando-shell)
    2. Wearde - tagongstoken út paragraaf 9
    3. Selektearje Mask fariabele
       

Dit foltôget de pre-konfiguraasje.

It tarieden fan it konfiguraasjekader

Standert brûkt CI / CD-konfiguraasje yn GitLab it bestân .gitlab-ci.yml fan 'e root fan' e repository. Jo kinne in willekeurige paad nei dit bestân ynstelle yn 'e repository-ynstellingen, mar yn dit gefal is it net nedich.

Lykas jo kinne sjen fan 'e tafoeging, befettet it bestân in konfiguraasje yn it formaat YAML. De dokumintaasje beskriuwt hokker kaaien kinne wurde befette op it boppeste nivo fan 'e konfiguraasje, en op elk fan' e nestele nivo's.

Litte wy earst in keppeling tafoegje oan it dockerôfbylding yn it konfiguraasjetriem, wêryn de taken wurde útfierd. Dêrfoar fine wy .Net Core-ôfbyldingsside op Docker Hub. de GitHub d'r is in detaillearre gids oer hokker ôfbylding te kiezen foar ferskate taken. In ôfbylding mei .Net Core 3.1 is geskikt foar ús om te bouwen, dus fiel jo frij om de earste rigel ta te foegjen oan 'e konfiguraasje

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

No, as de pipeline wurdt lansearre fanút it Microsoft-ôfbyldingsrepository, sil de opjûne ôfbylding downloade wurde, wêryn alle taken fan 'e konfiguraasje sille wurde útfierd.

De folgjende stap is te foegjen toaniel's. Standert definieart GitLab 5 stadia:

• .pre - útfierd oant alle stadia,
• .post - útfierd nei alle stadia,
• build - earst nei .pre poadium,
• test - twadde faze,
• deploy - de tredde etappe.

Neat foarkomt jo lykwols om se eksplisyt te ferklearjen. De folchoarder wêryn't de stappen wurde neamd, hat ynfloed op de folchoarder wêryn't se wurde útfierd. Litte wy foar folsleinens tafoegje oan 'e konfiguraasje:

stages:
  - build
  - test
  - deploy

Foar debuggen hat it sin om ynformaasje te krijen oer de omjouwing wêryn de taken wurde útfierd. Litte wy in globale set fan kommando's tafoegje dy't sil wurde útfierd foar elke taak mei before_script:

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

It bliuwt om op syn minst ien taak ta te foegjen, sadat as de commits wurde ferstjoerd, de pipeline sil begjinne. Litte wy no in lege taak tafoegje om te demonstrearjen:

dummy job:
  script:
    - echo ok

Wy begjinne validaasje, wy krije in berjocht dat alles goed is, wy commit, wy triuwe, wy sjogge nei de resultaten op 'e side ... En wy krije in skriptflater - bash: .PSVersion: command not found. wtf?

Alles is logysk - standert brûke runners (ferantwurdlik foar it útfieren fan taakskripts en levere troch GitLab) bash kommando's út te fieren. Jo kinne dit reparearje troch yn 'e taakbeskriuwing eksplisyt oan te jaan hokker tags de útfierende pipeline runner moat hawwe:

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

Grut! De pipeline rint no.

In oandachtige lêzer, nei't de oanjûne stappen werhelle binne, sil fernimme dat de taak yn 'e poadium is foltôge test, hoewol't wy net oantsjutte it poadium. Sa't jo miskien riede test is de standert stap.

Litte wy trochgean mei it meitsjen fan it konfiguraasjeskelet troch alle hjirboppe beskreaune taken ta te foegjen:

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

Wy krigen in net bysûnder funksjonele, mar dochs korrekte pipeline.

Triggers ynstelle

Fanwegen it feit dat gjin triggerfilters binne spesifisearre foar ien fan 'e taken, sil de pipeline folslein wurde útfierd elke kear as in commit wurdt skood nei it repository. Om't dit yn it algemien net it winske gedrach is, sille wy triggerfilters foar taken ynstelle.

Filters kinne wurde konfigureare yn twa formaten: allinne / útsein и regels. Koartsein, only/except kinne jo filters konfigurearje troch triggers (merge_request, bygelyks - stelt de taak út te fieren eltse kear in pull fersyk wurdt oanmakke en eltse kear commits wurde stjoerd nei de branch dat is de boarne yn de fúzje fersyk) en branch nammen (ynklusyf it brûken fan reguliere útdrukkingen); rules lit jo in set betingsten oanpasse en, opsjoneel, de betingst foar útfiering fan taak feroarje ôfhinklik fan it sukses fan eardere taken (when yn GitLab CI/CD).

Lit ús in set fan easken ûnthâlde - assemblage en testen allinich foar fúzjefersyk, ferpakking en ferstjoeren nei Azure DevOps - foar fúzjefersyk en push nei de master, dokumintaasje generaasje - foar push nei de master.

Litte wy earst de koade bouwtaak ynstelle troch in regel ta te foegjen dy't allinich op fúzje-oanfraach fjoer:

build job:
  # snip
  only:
    - merge_request

Litte wy no de ferpakkingstaak ynstelle om it fúzjefersyk te fjoerjen en commits ta te foegjen oan 'e master:

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

Sa't jo sjen kinne, alles is ienfâldich en rjochtlinich.

Jo kinne de taak ek ynstelle om allinich te fjoerjen as in fúzjefersyk is makke mei in spesifyk doel of boarnetûke:

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

Under betingsten kinne jo gebrûk meitsje fariabelen listed hjir; regels rules ynkompatibel mei de regels only/except.

Artifact Saving ynstelle

Tidens in taak build job wy sille artefakten bouwe dy't kinne wurde opnij brûkt yn folgjende taken. Om dit te dwaan, moatte jo de paden tafoegje oan 'e taakkonfiguraasje, de bestannen wêrmei jo moatte bewarje en opnij brûke yn' e folgjende taken, oan 'e kaai artifacts:

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

Paden stypje jokertekens, wat se perfoarst makliker makket om yn te stellen.

As in taak artefakten makket, dan sil elke folgjende taak tagong kinne krije - se sille lâns deselde paden lizze relatyf oan 'e repositoryroot dy't waarden sammele út' e orizjinele taak. Artefakten binne ek te downloaden op 'e side.

No't wy it konfiguraasjekader klear hawwe (en hifke), kinne wy ​​trochgean mei it feitlik skriuwen fan skripts foar taken.

Wy skriuwe skripts

Miskien, eartiids, yn in galaxy fier, fier fuort, it bouwen fan projekten (ynklusyf dy op .net) fan 'e kommandorigel wie in pine. No kinne jo it projekt bouwe, testen en publisearje yn 3 teams:

dotnet build
dotnet test
dotnet pack

Fansels binne d'r guon nuânses wêrtroch't wy de kommando's wat komplisearje.

1. Wy wolle in release build, net in debug build, sadat wy tafoegje oan elk kommando -c Release
2. By it testen wolle wy koadedekkingsgegevens sammelje, dus moatte wy in dekkingsanalysator opnimme yn 'e testbiblioteken:
   1. Foegje it pakket ta oan alle testbiblioteken coverlet.msbuild: dotnet add package coverlet.msbuild út projekt map
   2. Taheakje oan it test run kommando /p:CollectCoverage=true
   3. Foegje in kaai ta oan 'e testtaakkonfiguraasje om dekkingsresultaten te krijen (sjoch hjirûnder)
3. By it ynpakken fan de koade yn nuget-pakketten, set de útfiermap foar de pakketten yn: -o .

It sammeljen fan koadedekkingsgegevens

Nei it útfieren fan de tests printet Coverlet runstatistiken nei de konsole:

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 lit jo in reguliere útdrukking opjaan om statistiken te krijen, dy't dan kinne wurde krigen yn 'e foarm fan in badge. De reguliere ekspresje wurdt oantsjutte yn 'e taakynstellingen mei de kaai coverage; de útdrukking moat in capture groep befetsje, wêrfan de wearde wurdt trochjûn oan it badge:

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

Hjir krije wy statistiken fan in line mei totale line dekking.

Publisearje pakketten en dokumintaasje

Beide aksjes binne pland foar de lêste etappe fan 'e pipeline - sûnt de gearstalling en testen binne trochjûn, kinne wy ​​ús ûntwikkelingen diele mei de wrâld.

Besykje earst te publisearjen nei de pakketboarne:

1. As it projekt gjin nuget-konfiguraasjetriem hat (nuget.config), meitsje in nij: dotnet new nugetconfig

   Foar wat: de ôfbylding kin gjin skriuwtagong hawwe ta globale (brûker en masine) konfiguraasjes. Om flaters net te fangen, meitsje wy gewoan in nije lokale konfiguraasje en wurkje dermei.

2. Litte wy in nije pakketboarne tafoegje oan 'e lokale konfiguraasje: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
   1. name - lokale boarne namme, net kritysk
   2. url - URL fan 'e boarne fan it poadium "Accounts tariede", p. 6
   3. organization - organisaasjenamme yn Azure DevOps
   4. gitlab variable - de namme fan 'e fariabele mei it tagongstoken tafoege oan GitLab ("Accounts tariede", s. 11). Fansels, yn it formaat $variableName
   5. -StorePasswordInClearText - in hack om de tagong wegere flater te omgean (Ik bin net de earste dy't op dizze rake stapt)
   6. Yn gefal fan flaters kin it handich wêze om ta te foegjen -verbosity detailed
3. It pakket ferstjoere nei de boarne: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
   1. Wy stjoere alle pakketten út de hjoeddeiske map, dus *.nupkg.
   2. name - fan 'e stap hjirboppe.
   3. key - elke line. Yn Azure DevOps, yn it finster Ferbine mei feed, is it foarbyld altyd de line az.
   4. -skipduplicate - as jo besykje in al besteand pakket te ferstjoeren sûnder dizze kaai, sil de boarne in flater weromjaan 409 Conflict; mei de kaai, ferstjoeren wurdt oerslein.

Litte wy no it oanmeitsjen fan dokumintaasje ynstelle:

1. Earst, yn it repository, yn 'e mastertûke, inisjalisearje wy it docfx-projekt. Om dit te dwaan, fier it kommando út 'e root docfx init en ynteraktyf set de kaai parameters foar gebou dokumintaasje. Detaillearre beskriuwing fan 'e minimale projektopset hjir.
   1. By it konfigurearjen is it wichtich om de útfiermap op te jaan ..public - GitLab nimt standert de ynhâld fan 'e iepenbiere map yn' e root fan 'e repository as boarne foar Pages. Omdat it projekt sil lizze yn in map nestele yn 'e repository - foegje in útfier ta oan it nivo omheech yn it paad.
2. Litte wy de wizigingen nei GitLab drukke.
3. Foegje in taak ta oan de pipeline konfiguraasje pages (reservearre wurd foar side-publisearjende taken yn GitLab-siden):
   1. Skrift:
      1. nuget install docfx.console -version 2.51.0 - ynstallearje docfx; de ferzje wurdt oantsjutte om te soargjen dat de pakket ynstallaasje paden binne korrekt.
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - sammelje dokumintaasje
   2. Node artefakten:

pages:
  # snip
  artifacts:
    paths:
      - public

Lyryske digression oer docfx

Earder haw ik by it opsetten fan in projekt de koadeboarne foar de dokumintaasje spesifisearre as oplossingsbestân. It wichtichste neidiel is dat dokumintaasje ek makke wurdt foar testprojekten. As dit net nedich is, kinne jo dizze wearde ynstelle op it knooppunt metadata.src:

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

1. metadata.src.src: "../" - wy geane ien nivo omheech relatyf oan de lokaasje docfx.json, omdat yn patroanen, it opsykjen fan de mapbeam wurket net.
2. metadata.src.files: ["**/*.csproj"] - in wrâldwide patroan, wy sammelje alle C #-projekten út alle mappen.
3. metadata.src.exclude: ["*.tests*/**"] - globale patroan, útslute alles út mappen mei .tests Yn de titel

Subtotaal

Sa'n ienfâldige konfiguraasje kin makke wurde yn mar in heal oere en in pear bekers kofje, wêrtroch jo kinne kontrolearje dat de koade is boud en de tests passe, in nij pakket bouwe, de dokumintaasje bywurkje en it each mei moaie badges yn 'e README fan it projekt mei elk fúzjefersyk en ferstjoeren nei de master.

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

Oer badges sprutsen

Troch harren wie ommers alles begûn!

Badges mei pipelinestatussen en koadedekking binne beskikber yn GitLab yn 'e CI / CD-ynstellingen yn it Gtntral-pipelinesblok:

Ik makke in badge mei in keppeling nei de dokumintaasje op it platfoarm shields.io - alles is dêr frij ienfâldich, jo kinne jo eigen badge oanmeitsje en it ûntfange mei in fersyk.

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

Azure DevOps Artifacts kinne jo ek badges meitsje foar pakketten mei de lêste ferzje. Om dit te dwaan, yn 'e boarne op' e Azure DevOps-side, moatte jo klikke op Meitsje badge foar it selekteare pakket en kopiearje de markdown-markup:

It tafoegjen fan skientme

Markearje Common konfiguraasjefragminten

Wylst ik de konfiguraasje skreau en troch de dokumintaasje socht, kaam ik in nijsgjirrige eigenskip fan YAML tsjin - fragminten opnij brûke.

Lykas jo kinne sjen fan 'e taakynstellingen, hawwe se allegear de tag nedich windows by de loper, en wurde aktivearre as in fúzje fersyk wurdt stjoerd nei de master / oanmakke (útsein dokumintaasje). Litte wy dit tafoegje oan it fragmint dat wy opnij sille brûke:

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

En no kinne wy ​​​​it earder ferklearre fragmint ynfoegje yn 'e taakbeskriuwing:

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

Fragmintnammen moatte begjinne mei in stip, om net as in taak ynterpretearre te wurden.

Ferzjeferzje fan pakket

By it meitsjen fan in pakket kontroleart de kompilator de kommandorigelskeakels, en yn har ôfwêzigens, de projektbestannen; as it in Ferzjeknooppunt fynt, nimt it syn wearde as de ferzje fan it pakket dat wurdt boud. It docht bliken dat om in pakket mei in nije ferzje te bouwen, jo it moatte bywurkje yn it projektbestân of it trochjaan as in kommandorigelargument.

Litte wy noch ien winsk taheakje - lit de lytse twa nûmers yn 'e ferzje it jier wêze en de boudatum fan it pakket, en foegje foarferzjeferzjes ta. Fansels kinne jo dizze gegevens tafoegje oan it projektbestân en kontrolearje foar elke yntsjinjen - mar jo kinne it ek dwaan yn 'e pipeline, de pakketferzje sammelje út' e kontekst en it trochjaan troch it kommandorigelargument.

Litte wy it iens wêze dat as it commit-berjocht in line lykas befettet release (v./ver./version) <version number> (rev./revision <revision>)?, dan sille wy de ferzje fan it pakket fan dizze rigel nimme, it oanfolje mei de hjoeddeistige datum en it as argumint trochjaan oan it kommando dotnet pack. By it ûntbrekken fan in rigel sille wy it pakket gewoan net sammelje.

It folgjende skript lost dit probleem op:

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

In skript tafoegje oan in taak pack and deploy job en observearje de gearstalling fan pakketten strikt yn 'e oanwêzigens fan in opjûne tekenrige yn it commit-berjocht.

Totaal

Nei't wy sawat in heal oere as in oere hawwe bestege oan it skriuwen fan 'e konfiguraasje, debuggen yn' e lokale powershell en, mooglik, in pear mislearre lansearringen, krigen wy in ienfâldige konfiguraasje foar it automatisearjen fan routinetaken.

Fansels is GitLab CI / CD folle wiidweidiger en mearsidiger dan it liket nei it lêzen fan dizze hantlieding - dat is hielendal net wier. Dêr sels Auto DevOps istalitte

automatysk ûntdekke, bouwe, testen, ynsette en kontrolearje jo applikaasjes

No binne de plannen om in pipeline te konfigurearjen foar it ynsetten fan applikaasjes nei Azure, mei Pulumi en automatysk de doelomjouwing te bepalen, dy't yn it folgjende artikel behannele wurde.

Boarne: www.habr.com