ProHoster > Blogs > Administrācija > GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

Vai arÄ« kā iegÅ«t skaistas nozÄ«mÄ«tes savam projektam vienā mierÄ«gā kodÄ“Å”anas vakarā

DroÅ”i vien katram izstrādātājam, kuram kaut kad ir kaut viens mājdzÄ«vnieku projekts, niez pēc skaistām nozÄ«mÄ«tēm ar statusiem, koda pārklājumu, pakotņu versijām nuget... Un Ŕī nieze lika man uzrakstÄ«t Å”o rakstu. Gatavojoties tā rakstÄ«Å”anai, es ieguvu Å”o skaistumu vienā no saviem projektiem:

GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

Å ajā rakstā tiks apskatÄ«ta nepārtrauktas integrācijas un piegādes pamatiestatÄ«Å”ana .Net Core klases bibliotēkas projektam GitLab, dokumentācijas publicÄ“Å”ana GitLab lapās un apkopoto pakotņu nosÅ«tÄ«Å”ana uz privātu plÅ«smu pakalpojumā Azure DevOps.

VS kods ar paplaŔinājumu tika izmantots kā izstrādes vide GitLab darbplūsma (lai apstiprinātu iestatījumu failu tieŔi no izstrādes vides).

ÄŖss ievads

CD ir tad, kad tu tikko spiedi, bet klients jau visu pazaudējis?

Kas ir CI/CD un kāpēc tas ir vajadzÄ«gs?Var viegli pameklēt google. Atrodiet pilnÄ«gu dokumentāciju par cauruļvadu iestatÄ«Å”anu GitLab arÄ« viegli. Å eit es Ä«si un, ja iespējams, bez trÅ«kumiem, aprakstÄ«Å”u sistēmas procesu no putna lidojuma:

  • izstrādātājs nosÅ«ta saistÄ«bas krātuvei, izveido sapludināŔanas pieprasÄ«jumu, izmantojot vietni, vai kādā citā veidā tieÅ”i vai netieÅ”i palaiž cauruļvadu,
  • no konfigurācijas tiek atlasÄ«ti visi uzdevumi, kuru nosacÄ«jumi ļauj tos palaist noteiktā kontekstā,
  • uzdevumi tiek organizēti atbilstoÅ”i to posmiem,
  • posmi tiek izpildÄ«ti pēc kārtas - t.i. paralēli visi Ŕī posma uzdevumi ir izpildÄ«ti,
  • ja posms neizdodas (t.i., neizdodas vismaz viens no posma uzdevumiem) - cauruļvads apstājas (gandrÄ«z vienmēr),
  • ja visi posmi ir veiksmÄ«gi pabeigti, cauruļvads tiek uzskatÄ«ts par veiksmÄ«gu.

Tādējādi mums ir:

  • konveijera ir uzdevumu kopums, kas sakārtots posmos, kuros varat montēt, pārbaudÄ«t, pakotēt kodu, izvietot gatavo montāžu mākoņpakalpojumā utt.
  • posms (posms) ā€” cauruļvadu organizācijas vienÄ«ba, satur 1+ uzdevumu,
  • uzdevums (darbs) ir darba vienÄ«ba konveijerā. Sastāv no skripta (nepiecieÅ”ams), palaiÅ”anas nosacÄ«jumiem, iestatÄ«jumiem artefaktu publicÄ“Å”anai/keÅ”atmiņai un daudz ko citu.

AttiecÄ«gi CI/CD iestatÄ«Å”anas uzdevums ir izveidot uzdevumu kopu, kas Ä«steno visas nepiecieÅ”amās darbÄ«bas koda un artefaktu apkopoÅ”anai, testÄ“Å”anai un publicÄ“Å”anai.

Pirms sākam: kāpēc?

  • Kāpēc GitLab?

Jo, kad radās vajadzība izveidot privātas krātuves mājdzīvnieku projektiem, par tiem maksāja GitHub, un es biju mantkārīgs. Krātuves ir kļuvuŔas bezmaksas, taču pagaidām tas nav pietiekami labs iemesls, lai es pārietu uz GitHub.

  • Kāpēc ne Azure DevOps cauruļvadi?

Tā kā iestatÄ«Å”ana ir vienkārÅ”a ā€“ jums pat nav vajadzÄ«gas komandrindas zināŔanas. Integrācija ar ārējiem git nodroÅ”inātājiem ā€” ar pāris klikŔķiem, SSH atslēgu importÄ“Å”ana saistÄ«bu nosÅ«tÄ«Å”anai uz repozitoriju ā€” arÄ« konveijers ir viegli konfigurējams pat bez veidnes.

Sākuma pozīcija: kas jums ir un ko vēlaties

Mums ir:

  • repozitorijs GitLab.

Mēs gribam:

  • automātiska montāža un pārbaude katram apvienoÅ”anas pieprasÄ«jumam,
  • veidojot pakotnes katram sapludināŔanas pieprasÄ«jumam un nosÅ«tot uz galveno, ja apstiprinājuma ziņojumā ir noteikta rinda,
  • savākto pakotņu nosÅ«tÄ«Å”ana uz privātu plÅ«smu pakalpojumā Azure DevOps,
  • dokumentācijas apkopoÅ”ana un publicÄ“Å”ana GitLab lapās,
  • nozÄ«mÄ«tes!11

Aprakstītās prasības dabiski iekļaujas Ŕādā cauruļvada modelī:

  • 1. posms - montāža
    • Mēs savācam kodu, publicējam izvadfailus kā artefaktus
  • 2. posms - testÄ“Å”ana
    • Mēs saņemam artefaktus no izveides posma, veicam testus, apkopojam koda pārklājuma datus
  • 3. posms - nosÅ«tÄ«Å”ana
    • 1. uzdevums ā€” savāciet tÄ«rradņu pakotni un nosÅ«tiet to uz Azure DevOps
    • 2. uzdevums - mēs apkopojam vietni no xmldoc avota kodā un publicējam to GitLab lapās

Sāksim!

Konfigurācijas salikŔana

Kontu sagatavoŔana

  1. Izveidojiet kontu iekŔā Microsoft Azure

  2. Iet uz Azure DevOps

  3. Izveidojiet jaunu projektu

    1. Vārds - jebkurŔ
    2. Redzamība - jebkura
      GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

  4. NoklikŔķinot uz pogas Izveidot, projekts tiks izveidots un tiksiet novirzÄ«ts uz tā lapu. Å ajā lapā jÅ«s varat atspējot nevajadzÄ«gas funkcijas, dodoties uz projektu iestatÄ«jumiem (apakŔējā saite sarakstā kreisajā pusē -> Pārskats -> Azure DevOps pakalpojumu bloks)
    GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

  5. Atveriet sadaļu Atrifacts, noklikŔķiniet uz Izveidot plūsmu

    1. Ievadiet avota nosaukumu
    2. Izvēlieties redzamību
    3. Noņemiet atzÄ«mi no izvēles rÅ«tiņas Iekļaujiet pakotnes no plaÅ”i izplatÄ«tiem publiskiem avotiemlai avots nepārvērstos par tÄ«rradņa klona atkritumu izgāztuvi
      GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

  6. NoklikŔķiniet uz Connect to feed, atlasiet Visual Studio, kopējiet avotu no bloka Machine Setup
    GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

  7. Dodieties uz konta iestatījumiem, atlasiet Personiskā piekļuves pilnvara
    GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

  8. Izveidojiet jaunu piekļuves pilnvaru

    1. Nosaukums - patvaļīgs
    2. Organizācija ā€“ aktuāla
    3. DerÄ«guma termiņŔ: maksimāli 1 gads
    4. DarbÄ«bas joma ā€” iepakojums/lasÄ«Å”ana un rakstÄ«Å”ana
      GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

  9. Kopēt izveidoto marÄ·ieri - pēc modālā loga aizvērÅ”anas vērtÄ«ba nebÅ«s pieejama

  10. GitLab atveriet repozitorija iestatījumus, atlasiet CI/CD iestatījumi
    GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

  11. Izvērsiet mainīgo bloku un pievienojiet jaunu

    1. Nosaukums ā€” jebkurÅ” bez atstarpēm (bÅ«s pieejams komandu apvalkā)
    2. VērtÄ«ba ir piekļuves pilnvara no 9. darbÄ«bas
    3. Atlasiet maskas mainīgo
      GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

Tas pabeidz sākotnējo iestatÄ«Å”anu.

Konfigurācijas ietvara sagatavoŔana

Pēc noklusējuma fails, ko izmanto CI/CD konfigurÄ“Å”anai GitLab, ir .gitlab-ci.yml no repozitorija saknes. Repozitorija iestatÄ«jumos varat konfigurēt pielāgotu ceļu uz Å”o failu, taču Å”ajā gadÄ«jumā tas nav nepiecieÅ”ams.

Kā redzams no paplaÅ”inājuma, fails satur konfigurāciju formātā YAML. Dokumentācijā ir sÄ«ki aprakstÄ«ts, kādas atslēgas var ietvert konfigurācijas augŔējā lÄ«menÄ« un katrā ligzdotajā lÄ«menÄ«.

Vispirms konfigurācijas failam pievienosim saiti uz docker attēlu, kurā tiks izpildīti uzdevumi. Lai to izdarītu, mēs atrodam .Net Core attēlu lapa vietnē Docker Hub. Uz GitHub Ir detalizēts ceļvedis, kuru attēlu izvēlēties dažādiem uzdevumiem. Attēls ar .Net Core 3.1 ir piemērots mūsu izveidei, tāpēc pievienojiet to konfigurācijai kā pirmo rindiņu.

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

Tagad, palaižot cauruļvadu, norādītais attēls tiks lejupielādēts no Microsoft attēlu krātuves, kurā tiks izpildīti visi konfigurācijas uzdevumi.

Nākamais solis ir pievienot posmss. Pēc noklusējuma GitLab definē 5 posmus:

  • .pre - veikta visos posmos,
  • .post - izpildÄ«ts pēc visiem posmiem,
  • build - vispirms pēc .pre posms,
  • test - otrais posms,
  • deploy - treÅ”ais posms.

Tomēr nekas neliedz jums tos skaidri paziņot. KārtÄ«ba, kādā tiek uzskaitÄ«tas darbÄ«bas, ietekmē to izpildes secÄ«bu. Lai nodroÅ”inātu pilnÄ«gumu, pievienosim konfigurācijai:

stages:
  - build
  - test
  - deploy

AtkļūdoŔanai ir lietderīgi iegūt informāciju par vidi, kurā tiek izpildīti uzdevumi. Pievienosim globālu komandu kopu, kas tiks izpildīta pirms katra uzdevuma izmantoŔanas before_script:

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

Atliek pievienot vismaz vienu uzdevumu, lai, nosūtot saistības, tiktu sākta konveijera. Pagaidām demonstrācijai pievienosim tukŔu uzdevumu:

dummy job:
  script:
    - echo ok

Sākam validāciju, saņemam ziņojumu, ka viss kārtībā, apņemamies, spiežam, apskatām rezultātus vietnē... Un saņemam skripta kļūdu - bash: .PSVersion: command not found. WTF?

Viss ir loÄ£iski - pēc noklusējuma skrējēji (atbildÄ«gi par uzdevumu skriptu izpildi un nodroÅ”ina GitLab) izmanto bash lai izpildÄ«tu komandas. Varat to novērst, uzdevuma aprakstā skaidri norādot, kādiem tagiem jābÅ«t izpildÄ«tājam konveijera palaidējam:

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

Lieliski! Cauruļvads tagad darbojas.

UzmanÄ«gs lasÄ«tājs, atkārtojot Ŕīs darbÄ«bas, pamanÄ«s, ka uzdevums ir izpildÄ«ts posmā test, lai gan mēs nenorādÄ«jām posmu. Kā jÅ«s varētu nojaust, test ir noklusējuma solis.

Turpināsim konfigurācijas skeleta izveidi, pievienojot visus iepriekŔ aprakstītos uzdevumus:

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

Mēs saņēmām ne Ä«paÅ”i funkcionālu, bet tomēr pareizu cauruļvadu.

Trigeru iestatīŔana

Sakarā ar to, ka nevienam uzdevumam nav norādÄ«ti sprÅ«da filtri, konveijera tiks veikta pilnÄ«gi tiek izpildÄ«ts katru reizi, kad saistÄ«bas tiek nosÅ«tÄ«tas uz repozitoriju. Tā kā Ŕī darbÄ«ba kopumā nav vēlama, mēs konfigurēsim uzdevumu aktivizētājus.

Filtrus var konfigurēt divos formātos: tikai/izņemot Šø noteikumi. ÄŖsumā, only/except ļauj konfigurēt filtrus pēc trigeriem (merge_request, piemēram - konfigurē uzdevumu izpildi katru reizi, kad tiek izveidots sapludināŔanas pieprasÄ«jums un katru reizi, kad tiek nosÅ«tÄ«tas saistÄ«bas filiālei, kas ir sapludināŔanas pieprasÄ«juma avots) un filiāļu nosaukumus (tostarp izmantojot regulārās izteiksmes); rules ļauj pielāgot nosacÄ«jumu kopu un pēc izvēles mainÄ«t uzdevuma izpildes nosacÄ«jumu atkarÄ«bā no iepriekŔējo uzdevumu panākumiem (when GitLab CI/CD).

Atcerēsimies prasÄ«bu kopumu - montāža un testÄ“Å”ana tikai sapludināŔanas pieprasÄ«jumiem, iesaiņoÅ”ana un nosÅ«tÄ«Å”ana uz Azure DevOps - sapludināŔanas pieprasÄ«jumiem un nosÅ«tÄ«jumiem uz galveno, dokumentācijas Ä£enerÄ“Å”ana - pushem uz galveno.

Vispirms iestatÄ«sim koda montāžas uzdevumu, pievienojot trigera kārtulu, kas aktivizē tikai sapludināŔanas pieprasÄ«jumu:

build job:
  # snip
  only:
    - merge_request

Tagad konfigurēsim iepakoÅ”anas uzdevumu, lai aktivizētu sapludināŔanas pieprasÄ«jumu un pievienotu saistÄ«bas galvenajam:

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

Kā redzat, viss ir vienkārŔi un saprotami.

Varat arÄ« konfigurēt uzdevumu, lai tas tiktu aktivizēts tikai tad, ja sapludināŔanas pieprasÄ«jums ir izveidots ar noteiktu mērÄ·a vai avota atzaru:

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

Apstākļos to var izmantot Ŕeit uzskaitītie mainīgie; noteikumiem rules neatbilst noteikumiem only/except.

Artefaktu saglabāŔanas konfigurÄ“Å”ana

Kamēr uzdevums tiek izpildīts build job mums būs izveidoti artefakti, kurus varēs izmantot atkārtoti turpmākajos uzdevumos. Lai to izdarītu, atslēgai ir jāpievieno ceļi uzdevuma konfigurācijai, faili, pa kuriem būs jāsaglabā un atkārtoti jāizmanto nākamajos uzdevumos. artifacts:

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

Ceļi atbalsta aizstājējzÄ«mes, kas noteikti atvieglo to iestatÄ«Å”anu.

Ja uzdevums rada artefaktus, katrs nākamais uzdevums varēs tiem piekļūt - tie atradÄ«sies pa tiem paÅ”iem ceļiem attiecÄ«bā pret repozitorija sakni, pa kuru tie tika savākti no sākotnējā uzdevuma. Artefakti ir pieejami arÄ« lejupielādei vietnē.

Tagad, kad mums ir gatava (un pārbaudÄ«ta) konfigurācijas sistēma, mēs varam pāriet uz uzdevumu skriptu rakstÄ«Å”anu.

Mēs rakstām scenārijus

Iespējams, kādreiz tālu, tālu galaktikā būvniecības projekti (tostarp .net) no komandrindas bija sāpīgi. Tagad jūs varat salikt, pārbaudīt un publicēt projektu 3 komandās:

dotnet build
dotnet test
dotnet pack

Protams, ir dažas nianses, kuru dēļ mēs nedaudz sarežģīsim komandas.

  1. Mēs vēlamies laidienu, nevis atkļūdoÅ”anu, bÅ«vējumu, tāpēc pievienojam katrai komandai -c Release
  2. Pārbaudot, mēs vēlamies apkopot datus par koda pārklājumu, tāpēc mums ir jāpievieno pārklājuma analizators ar testa bibliotēkām:
    1. Pakete jāpievieno visām testa bibliotēkām coverlet.msbuild: dotnet add package coverlet.msbuild no projekta mapes
    2. Pievienojiet testa palaiŔanas komandai /p:CollectCoverage=true
    3. Pievienosim atslēgu testÄ“Å”anas uzdevuma konfigurācijai, lai iegÅ«tu pārklājuma rezultātus (skatiet tālāk)
  3. Iesaiņojot kodu tīrradņu pakotnēs, mēs iestatīsim pakotņu izvades direktoriju: -o .

Koda pārklājuma datu vākŔana

Pēc testu palaiÅ”anas Coverlet konsolē parāda palaiÅ”anas statistiku:

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 ļauj norādÄ«t regulāro izteiksmi, lai iegÅ«tu statistiku, ko pēc tam var iegÅ«t emblēmas veidā. Regulārā izteiksme ir norādÄ«ta uzdevuma iestatÄ«jumos ar taustiņu coverage; izteiksmē jāsatur uztverÅ”anas grupa, kuras vērtÄ«ba tiks pārnesta uz emblēmu:

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

Šeit mēs iegūstam statistiku no rindas ar kopējo pārklājumu pa rindām.

Mēs publicējam paketes un dokumentāciju

Mums ir abas darbÄ«bas, kas noteiktas cauruļvada pēdējam posmam - kopÅ” montāžas un pārbaudes ir pagājuÅ”as, mēs varam dalÄ«ties ar savu attÄ«stÄ«bu ar pasauli.

Vispirms apskatÄ«sim publicÄ“Å”anu pakotnes avotā:

  1. Ja projektam nav tīrradņa konfigurācijas faila (nuget.config), izveidojiet jaunu: dotnet new nugetconfig

    Par ko: Attēlam var nebÅ«t rakstÄ«Å”anas piekļuves globālajām (lietotāja un maŔīnas) konfigurācijām. Lai netiktu pieļautas kļūdas, mēs vienkārÅ”i izveidosim jaunu lokālo konfigurāciju un strādāsim ar to.

  2. Pievienosim vietējai konfigurācijai jaunu pakotnes avotu: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
    1. name ā€” vietējā avota nosaukums, nav svarÄ«gs
    2. url ā€” avota URL no posma ā€œKontu sagatavoÅ”anaā€, 6. darbÄ«ba
    3. organization - organizācijas nosaukums pakalpojumā Azure DevOps
    4. gitlab variable ā€” mainÄ«gā nosaukums ar GitLab pievienoto piekļuves pilnvaru (ā€œKontu sagatavoÅ”anaā€, 11. lpp.). Protams, formātā $variableName
    5. -StorePasswordInClearText ā€” uzlauÅ”ana, lai apietu piekļuves aizlieguma kļūdu (Es neesmu pirmais, kas uzkāpj uz Ŕī grābekļa)
    6. Kļūdu gadījumā var būt noderīgi pievienot -verbosity detailed
  3. Mēs nosūtām paku uz avotu: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
    1. Mēs sÅ«tām visas paketes no paÅ”reizējā direktorija, tāpēc *.nupkg.
    2. name - no iepriekÅ” minētā soļa.
    3. key - jebkura līnija. Programmas Azure DevOps logā Connect to feed piemēra rinda vienmēr ir az.
    4. -skipduplicate ā€” ja mēģināt nosÅ«tÄ«t jau esoÅ”u pakotni bez Ŕīs atslēgas, avots atgriezÄ«s kļūdu 409 Conflict; ar atslēgu, nosÅ«tÄ«Å”ana tiks izlaista.

Tagad iestatīsim dokumentācijas izveidi:

  1. Sākumā repozitorijā galvenajā filiālē mēs inicializējam docfx projektu. Lai to izdarÄ«tu, jums ir jāpalaiž komanda no saknes docfx init un interaktÄ«vi iestatiet galvenos parametrus dokumentācijas komplektÄ“Å”anai. Detalizēts minimālā projekta iestatÄ«Å”anas apraksts Å”eit.
    1. IestatÄ«Å”anas laikā ir svarÄ«gi norādÄ«t izvades direktoriju ..public - GitLab pēc noklusējuma izmanto repozitorija saknē esoŔās publiskās mapes saturu kā lapu avotu. Jo projekts atradÄ«sies mapē, kas ir ligzdots repozitorijā - pievienojiet ceļam izeju uz nākamo lÄ«meni.
  2. Izmaiņas virzīsim uz GitLab.
  3. Pievienojiet uzdevumu konveijera konfigurācijai pages (rezervēts vārds vietņu publicÄ“Å”anas uzdevumiem GitLab lapās):
    1. Skripts:
      1. nuget install docfx.console -version 2.51.0 - instalēt docfx; Versija tiek nodroÅ”ināta, lai nodroÅ”inātu, ka pakotnes instalÄ“Å”anas ceļi ir pareizi.
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json ā€” dokumentācijas vākÅ”ana
    2. Artefaktu mezgls:

pages:
  # snip
  artifacts:
    paths:
      - public

Liriska atkāpe par docfx

IepriekÅ”, veidojot projektu, kā risinājuma failu norādÄ«ju dokumentācijas koda avotu. Galvenais trÅ«kums ir tas, ka dokumentācija tiek veidota arÄ« testa projektiem. Ja tas nav nepiecieÅ”ams, varat iestatÄ«t Å”o vērtÄ«bu mezglam metadata.src:

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

  1. metadata.src.src: "../" ā€” ejiet vienu lÄ«meni uz augÅ”u attiecÄ«bā pret atraÅ”anās vietu docfx.json, jo MeklÄ“Å”ana direktoriju kokā nedarbojas modeļos.
  2. metadata.src.files: ["**/*.csproj"] ā€” globāls modelis, mēs apkopojam visus C# projektus no visiem direktorijiem.
  3. metadata.src.exclude: ["*.tests*/**"] - globāls modelis, izslēdziet visu no mapēm ar .tests Virsrakstā

Starpsumma

Å o vienkārÅ”o konfigurāciju var izveidot burtiski pusstundas un pāris kafijas tasÄ«Å”u laikā, kas ļaus ar katru sapludināŔanas pieprasÄ«jumu pārbaudÄ«t un nosÅ«tÄ«t meistaram, ka kods tiek veidots un testi iet, saliekot jaunu pakotni, aktualizējot dokumentāciju un iepriecinot aci ar skaistām nozÄ«mÄ«tēm projektā README.

Galīgais .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

Runājot par nozīmītēm

TieÅ”i viņu dēļ viss tika sākts!

Emblēmas ar konveijera statusiem un koda pārklājumu ir pieejamas GitLab CI/CD iestatījumos blokā Gtntral konveijera:

GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

Es izveidoju emblēmu ar saiti uz platformas dokumentāciju shields.io ā€” tur viss ir diezgan vienkārÅ”i, jÅ«s varat izveidot savu nozÄ«mÄ«ti un saņemt to, izmantojot pieprasÄ«jumu.

![ŠŸŃ€ŠøŠ¼ŠµŃ€ с Shields.io](https://img.shields.io/badge/custom-badge-blue)

GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

Azure DevOps Artifacts arÄ« ļauj izveidot emblēmas pakotnēm, kas norāda jaunāko versiju. Lai to izdarÄ«tu, Azure DevOps vietnes avotā jums jānoklikŔķina uz Izveidot emblēmu atlasÄ«tajai pakotnei un jākopē atzÄ«mes:

GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

GitLab CI/CD ceļvedis (gandrīz) absolūtiem iesācējiem

Skaistuma pievienoŔana

Mēs izceļam izplatītos konfigurācijas fragmentus

Rakstot konfigurāciju un pārmeklējot dokumentāciju, es uzgāju interesantu YAML funkciju - fragmentu atkārtotu izmantoÅ”anu.

Kā redzat no uzdevuma iestatÄ«jumiem, tiem visiem ir nepiecieÅ”ams tags windows no izpildÄ«tāja, un tiek aktivizēti, nosÅ«tot sapludināŔanas pieprasÄ«jumu galvenajam/veidojot sapludināŔanas pieprasÄ«jumu (izņemot dokumentāciju). Pievienosim Å”o fragmentam, ko izmantosim atkārtoti:

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

Un tagad mēs varam ievietot iepriekÅ” izziņoto fragmentu uzdevuma aprakstā:

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

Fragmentu nosaukumiem jāsākas ar punktu, lai netiktu interpretēts kā uzdevums.

Pakotnes versiju noteikŔana

Veidojot pakotni, kompilators pārbauda komandrindas slēdžus un, ja to nav, projekta failus; Pēc mezgla Version atraÅ”anas tas iegÅ«st tā vērtÄ«bu kā veidojamās pakotnes versiju. Izrādās, lai izveidotu pakotni ar jaunu versiju, tā ir jāatjaunina projekta failā vai jānodod kā komandrindas arguments.

Pievienosim vēl vienu vēlmi ā€“ lai divi mazākie skaitļi versijā ir pakotnes izveides gads un datums, un pievienojam pirmsizlaides versijas. Protams, jÅ«s varat pievienot Å”os datus projekta failam un pārbaudÄ«t tos pirms katras iesniegÅ”anas, taču varat to izdarÄ«t arÄ« konveijerā, savācot pakotnes versiju no konteksta un nododot to caur komandrindas argumentu.

Vienosimies, ja commit ziņojumā ir rindiņa patÄ«k release (v./ver./version) <version number> (rev./revision <revision>)?, tad mēs paņemsim pakotnes versiju no Ŕīs rindas, papildināsim to ar paÅ”reizējo datumu un nodosim to kā argumentu komandai dotnet pack. Ja nav lÄ«nijas, mēs vienkārÅ”i nesaliksim iepakojumu.

Å o problēmu atrisina Ŕāds skripts: 

# рŠµŠ³ŃƒŠ»ŃŃ€Š½Š¾Šµ Š²Ń‹Ń€Š°Š¶ŠµŠ½ŠøŠµ Š“Š»Ń ŠæŠ¾ŠøсŠŗŠ° стрŠ¾ŠŗŠø с Š²ŠµŃ€ŃŠøŠµŠ¹
$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

Skripta pievienoÅ”ana uzdevumam pack and deploy job un stingri ievērojiet paku salikÅ”anu, ja commit ziņojumā ir norādÄ«ta rinda.

Kopā

Pēc apmēram pusstundas lÄ«dz stundai, kas bija pavadÄ«ta konfigurācijas rakstÄ«Å”anai, atkļūdoÅ”anai vietējā Powershell un, iespējams, pāris neveiksmÄ«gām palaiÅ”anas reizēm, mēs saņēmām vienkārÅ”u konfigurāciju ikdienas uzdevumu automatizÄ“Å”anai.

Protams, GitLab CI/CD ir daudz plaŔāks un daudzpusÄ«gāks, nekā varētu Ŕķist pēc Ŕīs rokasgrāmatas izlasÄ«Å”anas - tā nemaz nav taisnÄ«ba. Ir pat Auto DevOps jāpieļaujot

automātiski noteikt, izveidot, pārbaudīt, izvietot un pārraudzīt jūsu lietojumprogrammas

Tagad ir plānots konfigurēt konveijeru lietojumprogrammu izvietoÅ”anai Azure, izmantojot Pulumi un automātiski nosakot mērÄ·a vidi, kas tiks aplÅ«kota nākamajā rakstā.

Avots: www.habr.com

Pievieno komentāru