🥇Opas CI/CD:hen GitLabissa (melkein) ehdottoman aloittelijalle

Tai kuinka saada kauniita merkkejä projektiisi yhtenä iltana helpolla koodauksella

Todennäköisesti jokainen kehittäjä, jolla on jossain vaiheessa ainakin yksi lemmikkiprojekti, kutinaa kauniita merkkejä, joissa on tilat, koodikattavuus, pakettiversiot nugetissa... Ja tämä kutina sai minut kirjoittamaan tämän artikkelin. Valmistellessani sen kirjoittamista sain tämän kauneuden yhdessä projektistani:

Tämä artikkeli opastaa sinut jatkuvan integroinnin ja toimituksen perusasetuksissa .Net Core -luokkakirjastoprojektille GitLabissa, dokumenttien julkaisemiseen GitLab-sivuille ja rakennettujen pakettien työntämiseen yksityiseen syötteeseen Azure DevOpsissa.

VS-koodia käytettiin kehitysympäristönä laajennuksen kanssa GitLabin työnkulku (asetustiedoston vahvistamiseen suoraan kehitysympäristöstä).

Lyhyt johdanto

CD - onko se kun vain työnsit, ja kaikki on jo pudonnut asiakkaan päälle?

Mikä on CI / CD ja miksi tarvitset sitä - voit helposti googlettaa sen. Löydä täydellinen dokumentaatio putkien määrittämisestä GitLabissa myös helppoa. Kuvaan tässä lyhyesti ja mahdollisuuksien mukaan ilman virheitä järjestelmän prosessia lintuperspektiivistä:

kehittäjä lähettää sitoumuksen arkistoon, luo yhdistämispyynnön sivuston kautta, tai jollakin muulla tavalla, suoraan tai epäsuorasti käynnistää liukuhihnan,
kaikki tehtävät valitaan kokoonpanosta, jonka ehdot sallivat niiden käynnistämisen annetussa kontekstissa,
tehtävät on järjestetty niiden vaiheiden mukaan,
vaiheet suoritetaan vuorotellen - ts. rinnakkain kaikki tämän vaiheen tehtävät on suoritettu,
jos vaihe epäonnistuu (eli ainakin yksi vaiheen tehtävistä epäonnistuu), liukuhihna pysähtyy (melkein aina),
jos kaikki vaiheet on suoritettu onnistuneesti, putkilinjan katsotaan onnistuneen.

Näin ollen meillä on:

putkisto - joukko tehtäviä, jotka on järjestetty vaiheisiin, joissa voit rakentaa, testata, paketoida koodia, ottaa valmiin koontiversion käyttöön pilvipalveluun jne.
vaihe (vaihe) — putken organisaatioyksikkö, sisältää 1+ tehtävän,
tehtävä (Työpaikka) on työn yksikkö. Se koostuu komentosarjasta (pakollinen), käynnistysehdoista, artefaktien julkaisu-/välimuistiasetuksista ja paljon muuta.

Vastaavasti CI / CD:tä määritettäessä tehtävä rajoittuu tehtäväsarjan luomiseen, joka toteuttaa kaikki tarvittavat toimet koodin ja artefaktien rakentamiseen, testaamiseen ja julkaisemiseen.

Ennen aloittamista: miksi?

Miksi Gitlab?

Koska kun tuli tarpeelliseksi luoda yksityisiä tietovarastoja lemmikkiprojekteille, ne maksettiin GitHubissa, ja olin ahne. Tietovarastot ovat tulleet ilmaisiksi, mutta toistaiseksi tämä ei ole riittävä syy minun siirtyä GitHubiin.

Miksei Azure DevOps Pipelines?

Koska siellä asetus on alkeellinen - komentorivin tuntemusta ei edes vaadita. Integrointi ulkoisten git-palveluntarjoajien kanssa - muutamalla napsautuksella SSH-avaimien tuonti sitoumusten lähettämiseksi arkistoon - myös putkilinja on helposti konfiguroitavissa, vaikka ei mallipohjasta.

Lähtöasento: mitä sinulla on ja mitä haluat

Meillä on:

arkisto GitLabissa.

Me haluamme:

automaattinen kokoonpano ja testaus jokaiselle yhdistämispyynnölle,
pakettien rakentaminen jokaiselle yhdistämispyynnölle ja isännälle työntäminen edellyttäen, että vahvistusviestissä on tietty rivi,
rakennettujen pakettien lähettäminen yksityiseen syötteeseen Azure DevOpsissa,
dokumentaation kokoaminen ja julkaisu GitLab-sivuilla,
merkit!11

Kuvatut vaatimukset kuuluvat orgaanisesti seuraavaan putkimalliin:

Vaihe 1 - kokoonpano
- Keräämme koodin, julkaisemme tulostiedostot artefakteina
Vaihe 2 - testaus
- Saamme artefakteja rakennusvaiheesta, suoritamme testejä ja keräämme koodin kattavuustietoja
Vaihe 3 - Lähetä
- Tehtävä 1 – luo nuget-paketti ja lähetä se Azure DevOpsiin
- Tehtävä 2 - keräämme sivuston xmldocista lähdekoodiin ja julkaisemme sen GitLab-sivuilla

Aloitetaan!

Kokoonpanon kerääminen

Tilien valmistelu

Luo tili sisään Microsoft Azure
Mene Azure DevOps
Luomme uuden projektin
1. Nimi - mikä tahansa
2. Näkyvyys - mikä tahansa
Kun napsautat Luo-painiketta, projekti luodaan ja sinut ohjataan sen sivulle. Tällä sivulla voit poistaa tarpeettomat ominaisuudet käytöstä siirtymällä projektiasetuksiin (alempi linkki vasemmalla olevassa luettelossa -> Yleiskatsaus -> Azure DevOps Services -lohko)
Siirry kohtaan Atrifacts ja napsauta Luo syöte
1. Anna lähteen nimi
2. Valitse näkyvyys
3. Poista valinta Sisällytä paketit yleisistä julkisista lähteistä, jotta lähde ei muutu dump nuget -klooniksi
Napsauta Yhdistä syötteeseen, valitse Visual Studio, kopioi lähde Koneen asennus -lohkosta
Siirry tilin asetuksiin ja valitse Personal Access Token
Luo uusi käyttöoikeustunnus
1. Nimi - mielivaltainen
2. Organisaatio - nykyinen
3. Voimassa enintään 1 vuoden
4. Soveltamisala - Pakkaus/Lue ja kirjoita
Kopioi luotu tunnus - modaaliikkunan sulkemisen jälkeen arvo ei ole käytettävissä
Siirry arkistoasetuksiin GitLabissa, valitse CI/CD-asetukset
Laajenna Muuttujat-lohko, lisää uusi
1. Nimi - mikä tahansa ilman välilyöntejä (saatavilla komentokuljessa)
2. Arvo - käyttöoikeustunnus kohdasta 9
3. Valitse Maskimuuttuja

Tämä päättää esikonfiguroinnin.

Konfigurointikehyksen valmistelu

Oletuksena GitLabin CI/CD-määritys käyttää tiedostoa .gitlab-ci.yml arkiston juuresta. Voit asettaa mielivaltaisen polun tälle tiedostolle arkiston asetuksissa, mutta tässä tapauksessa se ei ole välttämätöntä.

Kuten laajennuksesta näet, tiedosto sisältää määrityksen muodossa YAML. Dokumentaatiossa kerrotaan, mitkä avaimet voidaan sisältää kokoonpanon ylimmällä tasolla ja kullakin sisäkkäisellä tasolla.

Lisätään ensin linkki määritystiedostoon docker-kuvaan, jossa tehtävät suoritetaan. Tätä varten löydämme .Net Core -kuvasivu Docker Hubissa. Sisään GitHub siellä on yksityiskohtainen opas, mikä kuva valita eri tehtäviin. .Net Core 3.1 -kuva sopii meille rakentamiseen, joten voit lisätä ensimmäisen rivin kokoonpanoon

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

Nyt, kun liukuhihna käynnistetään Microsoftin kuvavarastosta, määritetty kuva ladataan, jossa kaikki määrityksen tehtävät suoritetaan.

Seuraava askel on lisätä vaihe's. Oletuksena GitLab määrittelee 5 vaihetta:

.pre - suoritettu kaikkiin vaiheisiin,
.post - suoritetaan kaikkien vaiheiden jälkeen,
build -ensin jälkeen .pre vaihe,
test - toinen vaihe,
deploy - kolmas vaihe.

Mikään ei kuitenkaan estä sinua ilmoittamasta niitä selvästi. Vaiheiden luettelointijärjestys vaikuttaa niiden suoritusjärjestykseen. Täydellisyyden vuoksi lisätään kokoonpanoon:

stages:
  - build
  - test
  - deploy

Virheenkorjausta varten on järkevää saada tietoa ympäristöstä, jossa tehtävät suoritetaan. Lisätään globaali joukko komentoja, jotka suoritetaan ennen jokaista tehtävää before_script:

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

Jäljelle jää vähintään yksi tehtävä, jotta kun commits lähetetään, liukuhihna alkaa. Lisätään nyt tyhjä tehtävä havainnollistamaan:

dummy job:
  script:
    - echo ok

Aloitamme validoinnin, saamme viestin, että kaikki on hyvin, sitoudumme, painamme, katsomme tuloksia sivustolla ... Ja saamme kirjoitusvirheen - bash: .PSVersion: command not found. mitä vittuu?

Kaikki on loogista - oletusarvoisesti juoksijat (vastaavat tehtäväskriptien suorittamisesta ja GitLabin toimittamat) käyttävät bash komentojen suorittamiseen. Voit korjata tämän määrittämällä tehtävän kuvauksessa nimenomaisesti, mitkä tunnisteet suorittavalla liukuhihnan juoksijalla tulisi olla:

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

Loistava! Putki on nyt käynnissä.

Huomaavainen lukija, toistanut ilmoitetut vaiheet, huomaa, että tehtävä on suoritettu vaiheessa test, vaikka emme täsmentäneet vaihetta. Kuten arvata saattaa test on oletusvaihe.

Jatketaan määritysrungon luomista lisäämällä kaikki yllä kuvatut tehtävät:

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

Saimme ei erityisen toimivan, mutta kuitenkin oikean putken.

Triggerien asettaminen

Koska yhdellekään tehtävälle ei ole määritetty liipaisusuodattimia, liukuhihna toimii täysin suoritetaan joka kerta, kun sitoumus työnnetään arkistoon. Koska tämä ei yleensä ole toivottu käyttäytyminen, asetamme tehtäville laukaisusuodattimet.

Suodattimet voidaan määrittää kahdessa muodossa: vain/paitsi и säännöt. Lyhyesti, only/except voit määrittää suodattimia triggereillä (merge_requestesimerkiksi - asettaa tehtävän suoritettavaksi joka kerta, kun vetopyyntö luodaan ja joka kerta, kun sitoumukset lähetetään haaralle, joka on yhdistämispyynnön lähde) ja haaran nimet (mukaan lukien säännöllisten lausekkeiden käyttö); rules voit mukauttaa ehtojoukkoa ja valinnaisesti muuttaa tehtävän suoritusehtoa aiempien tehtävien onnistumisen mukaan (when GitLab CI/CD:llä).

Muistetaan joukko vaatimuksia - kokoonpano ja testaus vain yhdistämispyynnöille, pakkaaminen ja lähettäminen Azure DevOpsiin - yhdistämispyynnöille ja työntöille isäntäkoneelle, dokumentaation luominen - työntöjä varten masterille.

Määritetään ensin koodinrakennustehtävä lisäämällä sääntö, joka käynnistyy vain yhdistämispyynnöstä:

build job:
  # snip
  only:
    - merge_request

Asetetaan nyt pakkaustehtävä käynnistämään yhdistämispyyntö ja lisätään sitoumuksia isäntäkoneeseen:

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

Kuten näet, kaikki on yksinkertaista ja suoraviivaista.

Voit myös asettaa tehtävän käynnistymään vain, jos yhdistämispyyntö luodaan tietyn kohteen tai lähdehaaran kanssa:

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

Ehtoja voidaan käyttää tässä luetellut muuttujat; säännöt rules sääntöjen vastainen only/except.

Artefakttien tallennuksen määrittäminen

Tehtävän aikana build job meillä on rakentaa artefakteja, joita voidaan käyttää uudelleen myöhemmissä tehtävissä. Tätä varten sinun on lisättävä avaimeen tehtäväkokoonpanon polut, tiedostot, joita pitkin sinun on tallennettava ja käytettävä uudelleen seuraavissa tehtävissä. artifacts:

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

Polut tukevat jokerimerkkejä, mikä helpottaa niiden määrittämistä.

Jos tehtävä luo artefakteja, jokainen seuraava tehtävä voi käyttää niitä - ne sijaitsevat samoilla poluilla suhteessa arkiston juureen, jotka kerättiin alkuperäisestä tehtävästä. Artefaktit ovat myös ladattavissa sivustolta.

Nyt kun konfigurointikehys on valmis (ja testattu), voimme edetä tehtävien komentosarjojen kirjoittamiseen.

Kirjoitamme käsikirjoituksia

Ehkä kerran kaukana, kaukana olevassa galaksissa rakennusprojektit (mukaan lukien .net-verkossa olevat) komentoriviltä oli tuskaa. Nyt voit rakentaa, testata ja julkaista projektin kolmessa tiimissä:

dotnet build
dotnet test
dotnet pack

Tietysti on joitain vivahteita, joiden vuoksi vaikeutamme komentoja jonkin verran.

Haluamme julkaisun koontiversion, emme virheenkorjauskoontiversion, joten lisäämme jokaiseen komentoon -c Release
Testattaessa haluamme kerätä koodin kattavuustietoja, joten meidän on sisällytettävä kattavuusanalysaattori testikirjastoihin:
1. Lisää paketti kaikkiin testikirjastoihin coverlet.msbuild: dotnet add package coverlet.msbuild projektikansiosta
2. Lisää testiajo-komentoon /p:CollectCoverage=true
3. Lisää avain testitehtävän kokoonpanoon saadaksesi kattavuustuloksia (katso alla)
Kun pakkaat koodia nuget-paketteihin, aseta pakettien lähtöhakemisto: -o .

Koodin kattavuustietojen kerääminen

Testien suorittamisen jälkeen Coverlet-tulosteet tulostavat tilastot konsoliin:

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% |
+---------+--------+--------+--------+

GitLabin avulla voit määrittää säännöllisen lausekkeen tilastotietojen saamiseksi, jotka voidaan sitten saada tunnuksen muodossa. Säännöllinen lauseke määritetään tehtävän asetuksissa -näppäimellä coverage; lausekkeen tulee sisältää sieppausryhmä, jonka arvo välitetään tunnukselle:

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

Täältä saamme tilastot linjasta, jolla on linjapeitto kokonaisuudessaan.

Julkaise paketteja ja dokumentaatiota

Molemmat toimet on suunniteltu putkilinjan viimeiseen vaiheeseen - koska kokoonpano ja testit on ohitettu, voimme jakaa kehitystyömme maailman kanssa.

Harkitse ensin julkaisemista pakettilähteeseen:

Jos projektilla ei ole nuget-määritystiedostoa (nuget.config), luo uusi: dotnet new nugetconfig

Minkä vuoksi: kuvalla ei ehkä ole kirjoitusoikeutta yleisiin (käyttäjän ja koneen) määrityksiin. Jotta virheitä ei havaita, luomme vain uuden paikallisen kokoonpanon ja työskentelemme sen kanssa.
Lisätään uusi pakettilähde paikalliseen kokoonpanoon: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - paikallisen lähteen nimi, ei kriittinen
2. url - Lähteen URL-osoite vaiheesta "Tilien valmistelu", kohta 6
3. organization - organisaation nimi Azure DevOpsissa
4. gitlab variable - sen muuttujan nimi, jonka käyttöoikeustunnus on lisätty GitLabiin ("Tilien valmistelu", s. 11). Luonnollisesti muodossa $variableName
5. -StorePasswordInClearText - hakkerointi pääsy estetty -virheen ohittamiseksi (En ole ensimmäinen, joka astuu tämän haravan päälle)
6. Virheiden sattuessa voi olla hyödyllistä lisätä -verbosity detailed
Paketin lähettäminen lähteelle: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Lähetämme kaikki paketit nykyisestä hakemistosta, joten *.nupkg.
2. name - yllä olevasta vaiheesta.
3. key - mikä tahansa rivi. Azure DevOpsin Yhdistä syötteeseen -ikkunassa esimerkki on aina rivi az.
4. -skipduplicate - Kun yritetään lähettää jo olemassa oleva paketti ilman tätä avainta, lähde palauttaa virheilmoituksen 409 Conflict; avaimella lähetys ohitetaan.

Asetetaan nyt dokumentaation luonti:

Ensin arkistossa, päähaarassa, alustamme docfx-projektin. Tee tämä suorittamalla komento juuresta docfx init ja määrittää interaktiivisesti rakennusdokumentaation keskeiset parametrit. Yksityiskohtainen kuvaus projektin vähimmäiskokoonpanosta täällä.
1. Konfiguroitaessa on tärkeää määrittää tuloshakemisto ..public - GitLab käyttää oletusarvoisesti arkiston juuressa olevan julkisen kansion sisältöä sivujen lähteenä. Koska projekti sijaitsee kansiossa, joka on arkistossa - lisää tulos polun tasolle.
Siirretään muutokset GitLabiin.
Lisää tehtävä liukuhihnan kokoonpanoon pages (varattu sana sivuston julkaisutehtäviin GitLab-sivuilla):
1. Käsikirjoitus:
  1. nuget install docfx.console -version 2.51.0 - asenna docfx; versio on määritetty varmistamaan, että paketin asennuspolut ovat oikeat.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - asiakirjojen kerääminen
2. Solmun artefaktit:

pages:
  # snip
  artifacts:
    paths:
      - public

Lyyrinen poikkeama docfx:stä

Aiemmin projektia perustaessani määritin dokumentaation koodilähteen ratkaisutiedostoksi. Suurin haittapuoli on, että dokumentaatiota luodaan myös testiprojekteihin. Jos tämä ei ole välttämätöntä, voit asettaa tämän arvon solmulle metadata.src:

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

metadata.src.src: "../" - nousta tasoa ylöspäin suhteessa sijaintiin docfx.json, koska kuvioissa haku hakemistopuusta ei toimi.
metadata.src.files: ["**/*.csproj"] - globaali malli, keräämme kaikki C # -projektit kaikista hakemistoista.
metadata.src.exclude: ["*.tests*/**"] - yleinen malli, sulje pois kaikki kansioista .tests Otsikossa

Välisumma

Tällainen yksinkertainen kokoonpano voidaan luoda vain puolessa tunnissa ja parissa kupissa kahvia, jonka avulla voit tarkistaa, että koodi on rakennettu ja testit läpäisseet, rakentaa uuden paketin, päivittää dokumentaatiota ja miellyttää silmää kauniilla merkit projektin README:ssä jokaisen yhdistämispyynnön ja isännälle lähettämisen yhteydessä.

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

Tunnusmerkeistä puheen ollen

Niiden ansiosta loppujen lopuksi kaikki alkoi!

Tunnusmerkit, joissa on liukuhihnan tilat ja koodin kattavuus, ovat saatavilla GitLabissa Gtntral-liukuhihnat-lohkon CI/CD-asetuksissa:

Loin tunnuksen, jossa on linkki alustan dokumentaatioon shields.io - Siellä kaikki on melko suoraviivaista, voit luoda oman tunnuksesi ja vastaanottaa sen pyynnöstä.

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

Azure DevOps Artifactsin avulla voit myös luoda merkkejä paketeille, joissa on uusin versio. Tätä varten sinun on napsautettava Azure DevOps -sivuston lähteessä Luo tunnus valitulle paketille ja kopioitava merkintämerkintä:

Lisää kauneutta

Yleisten konfiguraatiofragmenttien korostaminen

Asetuksia kirjoittaessani ja dokumentaatiota etsiessäni törmäsin YAML:n mielenkiintoiseen ominaisuuteen - fragmenttien uudelleenkäyttöön.

Kuten tehtäväasetuksista näkyy, ne kaikki vaativat tunnisteen windows juoksijassa, ja ne käynnistyvät, kun yhdistämispyyntö lähetetään pääkoneelle/luodulle (paitsi dokumentaatiota varten). Lisätään tämä fragmenttiin, jota käytämme uudelleen:

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

Ja nyt voimme lisätä aiemmin tehtävän kuvauksessa ilmoitetun fragmentin:

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

Fragmenttien nimien tulee alkaa pisteellä, jotta niitä ei tulkita tehtäväksi.

Paketin versiointi

Pakettia luodessaan kääntäjä tarkistaa komentorivin kytkimet ja niiden puuttuessa projektitiedostot; kun se löytää versiosolmun, se ottaa sen arvon rakennettavan paketin versiona. Osoittautuu, että jotta voit rakentaa paketin uudella versiolla, sinun on joko päivitettävä se projektitiedostoon tai välitettävä se komentoriviargumenttina.

Lisätään vielä yksi toivelista – olkoon versiossa olevat pienet kaksi numeroa paketin vuosi ja rakennuspäivämäärä, ja lisää esijulkaisuversiot. Tietenkin voit lisätä nämä tiedot projektitiedostoon ja tarkistaa ennen jokaista lähetystä - mutta voit myös tehdä sen käsittelyssä, keräämällä paketin version kontekstista ja välittämällä sen komentoriviargumentin kautta.

Sovitaan, että jos commit-viesti sisältää rivin like release (v./ver./version) <version number> (rev./revision <revision>)?, otamme paketin version tältä riviltä, täydennämme sitä nykyisellä päivämäärällä ja välitämme sen argumenttina komennon dotnet pack. Jos linjaa ei ole, emme yksinkertaisesti nouta pakettia.

Seuraava komentosarja ratkaisee tämän ongelman:

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

Skriptin lisääminen tehtävään pack and deploy job ja tarkkaile pakettien kokoamista tiukasti tietyn merkkijonon läsnä ollessa commit-sanomassa.

Yhteensä

Vietettyämme noin puolen tunnin tai tunnin kokoonpanon kirjoittamiseen, paikallisen powershellin virheenkorjauksen ja ehkä muutaman epäonnistuneen käynnistyksen jälkeen saimme yksinkertaisen konfiguraation rutiinitehtävien automatisoimiseen.

Tietenkin GitLab CI / CD on paljon laajempi ja monipuolisempi kuin miltä tämän oppaan lukemisen jälkeen saattaa näyttää - tuo ei ole ollenkaan totta. Siellä jopa Auto DevOps onsallimalla

tunnistaa, rakentaa, testata, ottaa käyttöön ja valvoa sovelluksiasi automaattisesti

Nyt on tarkoitus konfiguroida putki sovellusten käyttöönottoa varten Azuressa käyttämällä Pulumia ja määrittämällä automaattisesti kohdeympäristö, josta kerrotaan seuraavassa artikkelissa.

Lähde: will.com

GitLabin CI/CD-opas (melkein) absoluuttiselle aloittelijalle