🥇GitLab CI/CD vadovas (beveik) absoliučiam pradedančiajam

Arba kaip per vieną lengvo kodavimo vakarą gauti gražių ženklelių savo projektui

Tikriausiai kiekvienas kūrėjas, kuris tam tikru momentu turi bent vieną augintinio projektą, niežti dėl gražių ženklelių su būsenomis, kodo aprėpties, paketo versijų nuget... Ir šis niežulys paskatino mane parašyti šį straipsnį. Ruošdamasi jį rašyti, viename iš savo projektų gavau šį grožį:

Šiame straipsnyje bus aprašyta pagrindinė nuolatinio integravimo ir .Net Core klasės bibliotekos projekto „GitLab“ sąranka, dokumentacijos paskelbimas „GitLab“ puslapiuose ir sukurtų paketų perkėlimas į privatų „Azure DevOps“ sklaidos kanalą.

VS kodas buvo naudojamas kaip kūrimo aplinka su plėtiniu „GitLab“ darbo eiga (nustatymų failo patvirtinimui tiesiai iš kūrimo aplinkos).

Trumpas įvadas

CD - tai kai tik pastūmei, o viskas jau užgriuvo ant kliento?

Kas yra CI / CD ir kodėl jums to reikia – galite lengvai paieškoti „Google“. Raskite visą dokumentaciją apie vamzdynų konfigūravimą „GitLab“. taip pat lengvas. Čia trumpai ir, jei įmanoma, be trūkumų aprašysiu sistemos eigą iš paukščio skrydžio:

kūrėjas siunčia įsipareigojimą saugyklai, sukuria sujungimo užklausą per svetainę, arba kokiu nors kitu būdu tiesiogiai ar netiesiogiai pradeda dujotiekį,
visos užduotys parenkamos iš konfigūracijos, kurios sąlygos leidžia jas paleisti tam tikrame kontekste,
užduotys organizuojamos pagal jų etapus,
etapai vykdomi paeiliui – t.y. lygiagretus visos šio etapo užduotys atliktos,
jei etapas sugenda (t. y. nepavyksta bent viena iš etapo užduočių), dujotiekis sustoja (beveik visada),
jei visi etapai baigti sėkmingai, dujotiekis laikomas sėkmingu.

Taigi, mes turime:

vamzdynas – užduočių rinkinys, suskirstytas į etapus, kurių metu galite kurti, išbandyti, supakuoti kodą, įdiegti užbaigtą kūrimą debesies paslaugoje ir pan.
etapas (etapas) – vamzdyno organizavimo padalinys, kuriame yra 1+ užduotis,
užduotis (darbas) yra atliekamo darbo vienetas. Jį sudaro scenarijus (privalomas), paleidimo sąlygos, artefaktų paskelbimo / talpyklos nustatymai ir daug daugiau.

Atitinkamai, CI / CD nustatymo užduotis yra sukurti užduočių rinkinį, kuris įgyvendina visus būtinus veiksmus kuriant, testuojant ir publikuojant kodą ir artefaktus.

Prieš pradedant: kodėl?

Kodėl Gitlab?

Nes kai reikėjo kurti privačias saugyklas naminių gyvūnėlių projektams, už juos buvo mokama GitHub, o aš buvau godus. Saugyklos tapo nemokamos, tačiau kol kas tai nėra pakankama priežastis man pereiti prie „GitHub“.

Kodėl gi ne „Azure DevOps Pipelines“?

Nes ten nustatymas elementarus – komandinės eilutės išmanymas net nereikalingas. Integracija su išoriniais git teikėjais – keliais paspaudimais importuojami SSH raktai, kad būtų išsiųsti įsipareigojimai į saugyklą – taip pat dujotiekis lengvai konfigūruojamas net ne iš šablono.

Pradinė padėtis: ką turi ir ko nori

Mes turime:

„GitLab“ saugykla.

Mes norime:

automatinis surinkimas ir kiekvienos sujungimo užklausos testavimas,
kiekvienos sujungimo užklausos paketų kūrimas ir siuntimas pagrindiniam kompiuteriui, jei įsipareigojimo pranešime yra tam tikra eilutė,
sukurtų paketų siuntimas į privatų „Azure DevOps“ kanalą,
dokumentacijos surinkimas ir publikavimas GitLab puslapiuose,
ženkleliai!11

Aprašyti reikalavimai iš esmės patenka į šį dujotiekio modelį:

1 etapas - surinkimas
- Mes renkame kodą, publikuojame išvesties failus kaip artefaktus
2 etapas – testavimas
- Mes gauname artefaktus nuo kūrimo etapo, atliekame testus, renkame kodo aprėpties duomenis
3 etapas – pateikite
- 1 užduotis – sukurkite nuget paketą ir nusiųskite jį į Azure DevOps
- 2 užduotis – surenkame svetainę iš xmldoc šaltinio kode ir paskelbiame „GitLab“ puslapiuose

Pradėkime!

Konfigūracijos rinkimas

Sąskaitų ruošimas

Susikurkite paskyrą "Microsoft Azure"
Eiti į „Azure DevOps“
Kuriame naują projektą
1. Vardas – bet koks
2. Matomumas – bet koks
Paspaudus mygtuką Sukurti, projektas bus sukurtas ir būsite nukreipti į jo puslapį. Šiame puslapyje galite išjungti nereikalingas funkcijas, nuėję į projekto nustatymus (apatinė nuoroda sąraše kairėje -> Apžvalga -> Azure DevOps paslaugų blokas)
Eikite į Atrifacts, spustelėkite Kurti sklaidos kanalą
1. Įveskite šaltinio pavadinimą
2. Pasirinkite matomumą
3. Panaikinkite žymėjimą Įtraukite paketus iš įprastų viešųjų šaltinių, kad šaltinis nepavirstų grynuolio klonu
Spustelėkite Connect to feed, pasirinkite Visual Studio, nukopijuokite šaltinį iš mašinos sąrankos bloko
Eikite į paskyros nustatymus, pasirinkite „Personal Access Token“.
Sukurkite naują prieigos raktą
1. Vardas – savavališkas
2. Organizacija – dabartinė
3. Galioja ne ilgiau kaip 1 metus
4. Taikymo sritis – pakavimas / skaitymas ir rašymas
Nukopijuokite sukurtą žetoną - uždarius modalinį langą, vertė nebus pasiekiama
Eikite į saugyklos nustatymus „GitLab“, pasirinkite CI / CD nustatymus
Išplėskite bloką Kintamieji, pridėkite naują
1. Vardas – bet koks be tarpų (bus pasiekiamas komandų apvalkale)
2. Vertė – prieigos raktas iš 9 pastraipos
3. Pasirinkite kaukės kintamąjį

Tai užbaigia išankstinę konfigūraciją.

Konfigūracijos pagrindo paruošimas

Pagal numatytuosius nustatymus CI / CD konfigūracija „GitLab“ naudoja failą .gitlab-ci.yml nuo saugyklos šaknies. Saugyklos nustatymuose galite nustatyti savavališką šio failo kelią, tačiau šiuo atveju tai nėra būtina.

Kaip matote iš plėtinio, faile yra formato konfigūracija YAML. Dokumentacijoje išsamiai aprašoma, kurie raktai gali būti viršutiniame konfigūracijos lygyje ir kiekviename įdėtame lygyje.

Pirmiausia konfigūracijos faile pridėkime nuorodą į docker vaizdą, kuriame bus atliekamos užduotys. Tam mes randame „.Net Core“ vaizdų puslapis „Docker Hub“.. Į GitHub yra išsamus vadovas, kurį vaizdą pasirinkti įvairioms užduotims atlikti. Vaizdas su .Net Core 3.1 tinka mums sukurti, todėl nedvejodami pridėkite pirmąją konfigūracijos eilutę

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

Dabar, kai dujotiekis bus paleistas iš „Microsoft“ vaizdų saugyklos, bus atsisiųstas nurodytas vaizdas, kuriame bus vykdomos visos konfigūracijos užduotys.

Kitas žingsnis yra pridėti etapas's. Pagal numatytuosius nustatymus „GitLab“ apibrėžia 5 etapus:

.pre - atliekama iki visų etapų,
.post - atliekami po visų etapų,
build - pirmas po .pre scena,
test - antrasis etapas,
deploy - trečiasis etapas.

Tačiau niekas netrukdo jums jų aiškiai paskelbti. Veiksmų sąrašo tvarka turi įtakos jų atlikimo tvarkai. Norėdami išsamumo, pridėkime prie konfigūracijos:

stages:
  - build
  - test
  - deploy

Derinimui prasminga gauti informacijos apie aplinką, kurioje vykdomos užduotys. Pridėkime visuotinį komandų rinkinį, kuris bus vykdomas prieš kiekvieną užduotį before_script:

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

Belieka pridėti bent vieną užduotį, kad kai bus išsiųsti įsipareigojimai, būtų paleistas konvejeris. Dabar pridėkime tuščią užduotį, kad parodytume:

dummy job:
  script:
    - echo ok

Pradedame patvirtinimą, gauname pranešimą, kad viskas gerai, įsipareigojame, stumiame, žiūrime rezultatus svetainėje... Ir gauname scenarijaus klaidą - bash: .PSVersion: command not found. wtf?

Viskas logiška – pagal numatytuosius nustatymus bėgikai (atsakingi už užduočių scenarijų vykdymą ir pateikiami GitLab) naudoja bash komandoms vykdyti. Tai galite išspręsti užduoties aprašyme aiškiai nurodydami, kokias žymas turi turėti vykdantysis dujotiekio paleidiklis:

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

Puiku! Dujotiekis dabar veikia.

Dėmesingas skaitytojas, pakartojęs nurodytus veiksmus, pastebės, kad užduotis buvo atlikta etape test, nors etapo nenurodėme. Kaip galite atspėti test yra numatytasis žingsnis.

Tęskime konfigūracijos skeleto kūrimą pridėdami visas aukščiau aprašytas užduotis:

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

Gavome ne itin funkcionalų, bet vis dėlto teisingą vamzdyną.

Trigerių nustatymas

Dėl to, kad jokiai užduočiai nenurodyti paleidimo filtrai, dujotiekis bus visiškai būti vykdomas kiekvieną kartą, kai įsipareigojimas perkeliamas į saugyklą. Kadangi tai apskritai nėra pageidaujamas elgesys, mes nustatysime užduočių paleidimo filtrus.

Filtrus galima konfigūruoti dviem formatais: tik/išskyrus и taisyklės. Trumpai, only/except leidžia konfigūruoti filtrus pagal trigerius (merge_request, pavyzdžiui - nustato užduotį, kuri turi būti vykdoma kiekvieną kartą, kai sukuriama ištraukimo užklausa ir kiekvieną kartą, kai įsipareigojimai siunčiami filialui, kuris yra sujungimo užklausos šaltinis) ir šakų pavadinimus (įskaitant reguliariųjų išraiškų naudojimą); rules leidžia tinkinti sąlygų rinkinį ir, pasirinktinai, pakeisti užduoties vykdymo sąlygą, atsižvelgiant į ankstesnių užduočių sėkmę (when GitLab CI / CD).

Prisiminkime reikalavimų rinkinį – surinkimas ir testavimas tik sujungimo užklausai, pakavimas ir siuntimas į Azure DevOps – sujungimo užklausoms ir siuntimams į pagrindinį įrenginį, dokumentacijos generavimas – siuntimams į pagrindinį įrenginį.

Pirmiausia nustatykime kodo kūrimo užduotį pridėdami taisyklę, kuri suaktyvinama tik gavus sujungimo užklausą:

build job:
  # snip
  only:
    - merge_request

Dabar nustatykime pakavimo užduotį, kad ji suaktyvintų sujungimo užklausą ir pridėtų įsipareigojimų pagrindiniam serveriui:

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

Kaip matote, viskas paprasta ir aišku.

Taip pat galite nustatyti, kad užduotis būtų suaktyvinta tik tuo atveju, jei sujungimo užklausa sukuriama naudojant konkretų tikslą arba šaltinio šaką:

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

Esant sąlygoms, galite naudoti čia išvardyti kintamieji; taisykles rules nesuderinamas su taisyklėmis only/except.

Artefaktų išsaugojimo konfigūravimas

Vykdant užduotį build job turėsime kūrimo artefaktus, kuriuos bus galima pakartotinai panaudoti atliekant kitas užduotis. Norėdami tai padaryti, prie rakto turite pridėti kelius į užduoties konfigūraciją, failus, kuriuos turėsite išsaugoti ir pakartotinai naudoti atliekant šias užduotis. artifacts:

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

Keliai palaiko pakaitos simbolius, todėl juos lengviau nustatyti.

Jei užduotis sukuria artefaktus, kiekviena paskesnė užduotis galės juos pasiekti – jie bus išdėstyti tais pačiais keliais, palyginti su saugyklos šaknimi, kurie buvo surinkti iš pradinės užduoties. Svetainėje taip pat galima atsisiųsti artefaktus.

Dabar, kai turime paruoštą (ir išbandytą) konfigūracijos sistemą, galime pradėti iš tikrųjų rašyti užduočių scenarijus.

Rašome scenarijus

Galbūt kažkada toli, toli esančioje galaktikoje statyti projektus (įskaitant tuos, kurie yra .net) naudojant komandinę eilutę buvo sunku. Dabar galite kurti, išbandyti ir paskelbti projektą 3 komandose:

dotnet build
dotnet test
dotnet pack

Natūralu, kad yra keletas niuansų, dėl kurių komandas šiek tiek apsunkinsime.

Norime leidimo versijos, o ne derinimo versijos, todėl pridedame prie kiekvienos komandos -c Release
Testuodami norime rinkti kodo aprėpties duomenis, todėl į bandymų bibliotekas turime įtraukti aprėpties analizatorių:
1. Pridėkite paketą prie visų bandomųjų bibliotekų coverlet.msbuild: dotnet add package coverlet.msbuild iš projekto aplanko
2. Pridėkite prie bandomojo paleidimo komandos /p:CollectCoverage=true
3. Pridėkite raktą prie bandomosios užduoties konfigūracijos, kad gautumėte aprėpties rezultatus (žr. toliau)
Pakuodami kodą į nuget paketus, nustatykite paketų išvesties katalogą: -o .

Kodo aprėpties duomenų rinkimas

Paleidus testus, Coverlet spaudiniai paleidžia statistiką į konsolę:

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“ leidžia nurodyti reguliariąją išraišką, kad gautumėte statistiką, kurią vėliau galima gauti ženklelio pavidalu. Reguliari išraiška nurodoma užduoties nustatymuose klavišu coverage; išraiškoje turi būti užfiksuota grupė, kurios reikšmė bus perduota ženkleliui:

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

Čia gauname statistiką iš linijos su visa linijos aprėptimi.

Paskelbkite paketus ir dokumentus

Abu veiksmai numatyti paskutiniame dujotiekio etape – kadangi surinkimas ir bandymai baigėsi, galime pasidalinti savo pasiekimais su pasauliu.

Pirmiausia apsvarstykite galimybę paskelbti paketo šaltinyje:

Jei projektas neturi nuget konfigūracijos failo (nuget.config), sukurkite naują: dotnet new nugetconfig

Kam: vaizdas gali neturėti rašymo prieigos prie visuotinių (vartotojo ir mašinos) konfigūracijų. Kad nepagautume klaidų, tiesiog sukuriame naują vietinę konfigūraciją ir su ja dirbame.
Į vietinę konfigūraciją įtraukkime naują paketo šaltinį: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - vietinio šaltinio pavadinimas, nekritinis
2. url - Šaltinio URL iš etapo „Sąskaitų ruošimas“, 6 p
3. organization – organizacijos pavadinimas „Azure DevOps“.
4. gitlab variable - kintamojo su prieigos raktu, pridėtu prie GitLab, pavadinimas ("Paskyrų paruošimas", p. 11). Žinoma, formatu $variableName
5. -StorePasswordInClearText - įsilaužimas, siekiant apeiti uždraustos prieigos klaidą (Aš ne pirmas, užlipęs ant šio grėblio)
6. Jei yra klaidų, gali būti naudinga pridėti -verbosity detailed
Paketo siuntimas šaltiniui: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Mes siunčiame visus paketus iš esamo katalogo, todėl *.nupkg.
2. name - nuo aukščiau esančio žingsnio.
3. key - bet kokia linija. „Azure DevOps“ lange „Prisijungti prie informacijos santraukos“ pavyzdys visada yra eilutė az.
4. -skipduplicate - bandant išsiųsti jau esamą paketą be šio rakto, šaltinis grąžins klaidą 409 Conflict; su raktu siuntimas bus praleistas.

Dabar nustatykime dokumentacijos kūrimą:

Pirma, saugykloje, pagrindinėje šakoje, inicijuojame docfx projektą. Norėdami tai padaryti, paleiskite komandą iš šaknies docfx init ir interaktyviai nustatyti pagrindinius pastato dokumentacijos parametrus. Išsamus minimalios projekto sąrankos aprašymas čia.
1. Konfigūruojant svarbu nurodyti išvesties katalogą ..public - Pagal numatytuosius nustatymus „GitLab“ naudoja saugyklos šaknyje esančio viešojo aplanko turinį kaip puslapių šaltinį. Nes projektas bus aplanke, esančiame saugykloje – pridėkite išvestį kelyje į aukštesnį lygį.
Perkelkime pakeitimus į „GitLab“.
Pridėkite užduotį prie dujotiekio konfigūracijos pages (rezervuotas žodis svetainės publikavimo užduotims „GitLab“ puslapiuose):
1. Scenarijus:
  1. nuget install docfx.console -version 2.51.0 - įdiegti docfx; versija nurodyta siekiant užtikrinti, kad paketo diegimo keliai būtų teisingi.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - rinkti dokumentus
2. Mazgo artefaktai:

pages:
  # snip
  artifacts:
    paths:
      - public

Lyrinis nukrypimas apie docfx

Anksčiau kurdamas projektą dokumentacijos kodo šaltinį nurodydavau kaip sprendimo failą. Pagrindinis trūkumas – dokumentacija kuriama ir bandomiesiems projektams. Jei tai nėra būtina, galite nustatyti šią reikšmę mazgu metadata.src:

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

metadata.src.src: "../" - Mes kylame vienu lygiu aukštyn, palyginti su vieta docfx.json, nes šablonuose paieška katalogų medyje neveikia.
metadata.src.files: ["**/*.csproj"] - pasaulinis modelis, mes renkame visus C # projektus iš visų katalogų.
metadata.src.exclude: ["*.tests*/**"] - visuotinis modelis, išskirkite viską iš aplankų su .tests Pavadinime

Tarpinė suma

Tokią nesudėtingą konfigūraciją galima sukurti vos per pusvalandį ir porą puodelių kavos, kuri leis patikrinti, ar kodas sukurtas ir testai praeina, sukurti naują paketą, atnaujinti dokumentaciją ir pamaloninti akį gražiais ženkleliai projekto README su kiekviena sujungimo užklausa ir siuntimu pagrindiniam kompiuteriui.

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

Kalbant apie ženkliukus

Dėl jų juk viskas ir buvo pradėta!

Ženkliukai su konvejerio būsenomis ir kodo aprėptis yra prieinami „GitLab“ CI / CD nustatymuose, esančiuose „Gtntral“ konvejerijų bloke:

Sukūriau ženklelį su nuoroda į platformos dokumentaciją skydai.io - Ten viskas gana paprasta, galite susikurti savo ženklelį ir gauti jį pagal užklausą.

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

„Azure DevOps Artifacts“ taip pat leidžia kurti paketų su naujausia versija ženklelius. Norėdami tai padaryti, Azure DevOps svetainės šaltinyje turite spustelėti Sukurti pasirinkto paketo ženklelį ir nukopijuoti žymėjimo žymėjimą:

Grožio pridėjimas

Bendrų konfigūracijos fragmentų paryškinimas

Rašydamas konfigūraciją ir ieškodamas dokumentacijos, aptikau įdomią YAML savybę – pakartotinį fragmentų naudojimą.

Kaip matote iš užduočių nustatymų, jiems visiems reikia žymos windows paleidiklyje ir suveikia, kai pagrindiniam/sukurtam (išskyrus dokumentus) siunčiama sujungimo užklausa. Pridėkime tai prie fragmento, kurį naudosime pakartotinai:

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

Ir dabar galime įterpti fragmentą, deklaruotą anksčiau užduoties aprašyme:

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

Fragmentų pavadinimai turi prasidėti tašku, kad nebūtų interpretuojami kaip užduotis.

Paketo versijų kūrimas

Kurdamas paketą kompiliatorius tikrina komandų eilutės jungiklius, o jei jų nėra – projekto failus; kai jis randa versijos mazgą, jis įgauna jo vertę kaip kuriamo paketo versiją. Pasirodo, kad norint sukurti paketą su nauja versija, reikia jį atnaujinti projekto faile arba perduoti kaip komandinės eilutės argumentą.

Pridėkime dar vieną pageidavimų sąrašą – tegul du smulkūs versijos skaičiai yra paketo metai ir sukūrimo data, ir pridėkite išankstines versijas. Žinoma, galite įtraukti šiuos duomenis į projekto failą ir patikrinti prieš kiekvieną pateikimą, bet galite tai padaryti ir ruošdami rinkinį paketo versijai iš konteksto ir perduodant ją per komandinės eilutės argumentą.

Sutikime, kad jei įvykdymo pranešime yra eilutė kaip release (v./ver./version) <version number> (rev./revision <revision>)?, tada iš šios eilutės paimsime paketo versiją, papildysime ją dabartine data ir perduosime kaip argumentą komandai dotnet pack. Jei eilutės nėra, mes tiesiog neatimsime pakuotės.

Šis scenarijus išsprendžia šią problemą:

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

Scenarijaus pridėjimas prie užduoties pack and deploy job ir griežtai stebėkite paketų surinkimą, kai įvykdymo pranešime yra nurodyta eilutė.

Iš viso

Sugaišę apie pusvalandį ar valandą konfigūracijos rašymui, vietinio powershell derinimo ir, galbūt, poros nesėkmingų paleidimų, gavome paprastą konfigūraciją įprastų užduočių automatizavimui.

Žinoma, GitLab CI / CD yra daug platesnis ir daugialypesnis, nei gali atrodyti perskaičius šį vadovą - tai visai netiesa. Ten net „Auto DevOps“ yra, leidžiantis

automatiškai aptikti, kurti, išbandyti, diegti ir stebėti jūsų programas

Dabar planuojama sukonfigūruoti programų diegimo „Azure“ dujotiekį naudojant „Pulumi“ ir automatiškai nustatant tikslinę aplinką, apie kurią bus kalbama kitame straipsnyje.

Šaltinis: www.habr.com

GitLab CI / CD vadovas (beveik) absoliučiam pradedantiesiems