🥇Gids voor CI/CD in GitLab voor de (bijna) absolute beginner

Of hoe u in één avond met eenvoudige codering prachtige badges voor uw project kunt krijgen

Waarschijnlijk heeft elke ontwikkelaar die op zijn minst één huisdierproject heeft op een gegeven moment een jeuk over mooie badges met statussen, codedekking, pakketversies in nuget ... En deze jeuk bracht me ertoe dit artikel te schrijven. Ter voorbereiding op het schrijven ervan, kreeg ik deze schoonheid in een van mijn projecten:

Dit artikel leidt u door de basisconfiguratie van continue integratie en levering voor een .Net Core-klassebibliotheekproject in GitLab, het publiceren van documentatie naar GitLab Pages en het pushen van gebouwde pakketten naar een privéfeed in Azure DevOps.

VS Code werd gebruikt als ontwikkelomgeving met de extensie GitLab-workflow (voor validatie van het instellingenbestand rechtstreeks vanuit de ontwikkelomgeving).

Korte introductie

CD - is het wanneer je net hebt gepusht en alles al op de client is gevallen?

Wat is CI/CD en waarom heb je het nodig - je kunt het eenvoudig googlen. Vind volledige documentatie over het configureren van pijplijnen in GitLab ook makkelijk. Hier zal ik kort en, indien mogelijk, foutloos het proces van het systeem vanuit vogelperspectief beschrijven:

de ontwikkelaar stuurt een commit naar de repository, maakt een samenvoegverzoek aan via de site, of op een andere manier expliciet of impliciet de pijplijn start,
alle taken worden geselecteerd uit de configuratie, waarvan de voorwaarden het mogelijk maken om ze in de gegeven context te starten,
taken zijn georganiseerd volgens hun stadia,
stadia worden beurtelings uitgevoerd - d.w.z. parallel alle taken van deze fase zijn voltooid,
als de stage faalt (d.w.z. als ten minste één van de taken van de stage faalt), stopt de pijplijn (bijna altijd),
als alle fasen met succes zijn voltooid, wordt de pijplijn als succesvol beschouwd.

Zo hebben we:

pijplijn - een reeks taken georganiseerd in fasen waarin u kunt bouwen, testen, pakketcode kunt maken, een voltooide build naar een cloudservice kunt implementeren, enz.,
fase (stadium) - pijplijn organisatie-eenheid, bevat 1+ taak,
taak (baan) is een werkeenheid in de pijplijn. Het bestaat uit een script (verplicht), opstartvoorwaarden, instellingen voor het publiceren/cachen van artefacten en nog veel meer.

Dienovereenkomstig komt de taak bij het opzetten van CI / CD neer op het creëren van een reeks taken die alle noodzakelijke acties implementeren voor het bouwen, testen en publiceren van code en artefacten.

Voor aanvang: waarom?

Waarom Gitlab?

Omdat toen het nodig werd om privé-repository's voor huisdierprojecten te maken, ze op GitHub werden betaald, en ik was hebzuchtig. De repositories zijn gratis geworden, maar tot nu toe is dit voor mij niet genoeg reden om naar GitHub te verhuizen.

Waarom geen Azure DevOps-pijplijnen?

Omdat de instelling daar elementair is - kennis van de opdrachtregel is niet eens vereist. Integratie met externe git-providers - in een paar klikken, import van SSH-sleutels om commits naar de repository te sturen - ook, de pijplijn is eenvoudig te configureren, zelfs niet vanuit een sjabloon.

Uitgangspositie: wat je hebt en wat je wilt

We hebben:

opslagplaats in GitLab.

Wij willen:

automatische montage en testen voor elk samenvoegverzoek,
pakketten bouwen voor elk samenvoegverzoek en naar de master pushen, op voorwaarde dat er een bepaalde regel in het commit-bericht staat,
gebouwde pakketten verzenden naar een privéfeed in Azure DevOps,
montage van documentatie en publicatie in GitLab Pages,
insignes! 11

De beschreven eisen vallen organisch op het volgende pijplijnmodel:

Fase 1 - montage
- We verzamelen de code, publiceren de uitvoerbestanden als artefacten
Fase 2 - testen
- We halen artefacten uit de bouwfase, voeren tests uit, verzamelen codedekkingsgegevens
Fase 3 - Verzenden
- Taak 1: bouw het nuget-pakket en stuur het naar Azure DevOps
- Taak 2 - we verzamelen de site van xmldoc in de broncode en publiceren deze in GitLab Pages

Laten we beginnen!

De configuratie verzamelen

Rekeningen voorbereiden

Maak een account aan in Microsoft Azure
Ga naar Azure DevOps
We maken een nieuw project aan
1. Naam - elke
2. Zichtbaarheid - elk
Wanneer u op de knop Maken klikt, wordt het project gemaakt en wordt u doorgestuurd naar de bijbehorende pagina. Op deze pagina kunt u onnodige functies uitschakelen door naar de projectinstellingen te gaan (onderste link in de lijst aan de linkerkant -> Overzicht -> blok Azure DevOps Services)
Ga naar Atrifacts, klik op Feed maken
1. Voer de naam van de bron in
2. Kies zichtbaarheid
3. Vink uit Voeg pakketten toe van gemeenschappelijke openbare bronnen, zodat de bron niet verandert in een dump nuget-kloon
Klik op Connect to feed, selecteer Visual Studio, kopieer Source uit het blok Machine Setup
Ga naar accountinstellingen, selecteer Persoonlijk toegangstoken
Maak een nieuw toegangstoken aan
1. Naam - willekeurig
2. Organisatie - actueel
3. Maximaal 1 jaar geldig
4. Toepassingsgebied - Verpakking/Lezen & Schrijven
Kopieer het aangemaakte token - nadat het modale venster is gesloten, is de waarde niet meer beschikbaar
Ga naar de repository-instellingen in GitLab, selecteer de CI / CD-instellingen
Vouw het blok Variabelen uit en voeg een nieuwe toe
1. Naam - elke zonder spaties (zal beschikbaar zijn in de opdrachtshell)
2. Waarde - toegangstoken uit paragraaf 9
3. Selecteer Maskervariabele

Hiermee is de voorconfiguratie voltooid.

Het configuratieframework voorbereiden

Standaard gebruikt de CI/CD-configuratie in GitLab het bestand .gitlab-ci.yml vanuit de root van de repository. U kunt een willekeurig pad naar dit bestand instellen in de repository-instellingen, maar in dit geval is dat niet nodig.

Zoals u kunt zien aan de extensie, bevat het bestand een configuratie in het formaat YAML. De documentatie beschrijft welke sleutels op het hoogste niveau van de configuratie en op elk van de geneste niveaus kunnen worden opgenomen.

Laten we eerst een link toevoegen naar de docker-afbeelding in het configuratiebestand, waarin de taken zullen worden uitgevoerd. Hiervoor vinden we .Net Core-afbeeldingenpagina op Docker Hub. In GitHub er is een gedetailleerde gids over welke afbeelding u moet kiezen voor verschillende taken. Een image met .Net Core 3.1 is voor ons geschikt om te bouwen, dus voeg gerust de eerste regel toe aan de configuratie

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

Wanneer de pijplijn nu wordt gestart vanuit de Microsoft-afbeeldingsrepository, wordt de opgegeven afbeelding gedownload, waarin alle taken uit de configuratie worden uitgevoerd.

De volgende stap is toevoegen stadium'S. GitLab definieert standaard 5 fasen:

.pre - uitgevoerd tot alle stadia,
.post - uitgevoerd na alle stadia,
build - eerst daarna .pre fase,
test - tweede fase,
deploy - de derde fase.

Niets weerhoudt u er echter van om ze expliciet te declareren. De volgorde waarin de stappen worden vermeld, is van invloed op de volgorde waarin ze worden uitgevoerd. Laten we voor de volledigheid toevoegen aan de configuratie:

stages:
  - build
  - test
  - deploy

Voor foutopsporing is het zinvol om informatie te krijgen over de omgeving waarin de taken worden uitgevoerd. Laten we een globale set opdrachten toevoegen die vóór elke taak worden uitgevoerd met before_script:

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

Het blijft om ten minste één taak toe te voegen, zodat wanneer de commits worden verzonden, de pijplijn zal starten. Laten we voorlopig een lege taak toevoegen om te demonstreren:

dummy job:
  script:
    - echo ok

We starten de validatie, we krijgen een bericht dat alles in orde is, we committen ons, we pushen, we bekijken de resultaten op de site ... En we krijgen een scriptfout - bash: .PSVersion: command not found. wtf?

Alles is logisch - standaard gebruiken runners (verantwoordelijk voor het uitvoeren van taakscripts en geleverd door GitLab) bash commando's uit te voeren. U kunt dit oplossen door expliciet in de taakbeschrijving op te geven welke tags de uitvoerende pijplijnrunner moet hebben:

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

Geweldig! De pijplijn loopt nu.

Een oplettende lezer die de aangegeven stappen heeft herhaald, zal merken dat de taak in de fase is voltooid test, hoewel we het podium niet hebben gespecificeerd. Zoals je zou kunnen raden test is de standaardstap.

Laten we doorgaan met het maken van het configuratieskelet door alle hierboven beschreven taken toe te voegen:

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

We hebben een niet bijzonder functionele, maar toch correcte pijplijn.

Triggers instellen

Vanwege het feit dat er geen triggerfilters zijn opgegeven voor een van de taken, zal de pijplijn dat wel doen geheel worden uitgevoerd elke keer dat een commit naar de repository wordt gepusht. Aangezien dit over het algemeen niet het gewenste gedrag is, zullen we triggerfilters voor taken instellen.

Filters kunnen in twee formaten worden geconfigureerd: alleen/behalve и reglement. Kort, only/except stelt u in staat filters te configureren op basis van triggers (merge_request, bijvoorbeeld - stelt de taak in die moet worden uitgevoerd elke keer dat een pull-verzoek wordt gemaakt en elke keer dat commits worden verzonden naar de branch die de bron is in het samenvoegverzoek) en branch-namen (inclusief het gebruik van reguliere expressies); rules stelt u in staat een reeks voorwaarden aan te passen en, optioneel, de uitvoeringsvoorwaarde van de taak te wijzigen, afhankelijk van het succes van eerdere taken (when in GitLab CI/CD).

Laten we een aantal vereisten terugroepen: alleen assembleren en testen voor samenvoegverzoeken, verpakken en verzenden naar Azure DevOps - voor samenvoegverzoeken en pushs naar de master, documentatiegeneratie - voor pushs naar de master.

Laten we eerst de taak voor het maken van code instellen door een regel toe te voegen die alleen wordt geactiveerd bij een samenvoegverzoek:

build job:
  # snip
  only:
    - merge_request

Laten we nu de verpakkingstaak instellen om op het samenvoegverzoek te vuren en commits aan de master toe te voegen:

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

Zoals u kunt zien, is alles eenvoudig en duidelijk.

U kunt de taak ook zo instellen dat deze alleen wordt geactiveerd als er een samenvoegverzoek wordt gemaakt met een specifieke doel- of bronvertakking:

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

Onder voorwaarden kunt u gebruiken hier vermelde variabelen; reglement rules onverenigbaar met de regels only/except.

Artefacten opslaan configureren

Tijdens een taak build job we zullen artefacten bouwen die kunnen worden hergebruikt in volgende taken. Om dit te doen, moet u de paden naar de taakconfiguratie, de bestanden waarlangs u moet opslaan en hergebruiken in de volgende taken, toevoegen aan de sleutel artifacts:

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

Paden ondersteunen jokertekens, waardoor ze beslist gemakkelijker in te stellen zijn.

Als een taak artefacten creëert, dan zal elke volgende taak er toegang toe hebben - ze zullen zich langs dezelfde paden bevinden ten opzichte van de repository-root die werden verzameld van de oorspronkelijke taak. Artefacten zijn ook beschikbaar om te downloaden op de site.

Nu we een configuratieframework klaar hebben (en getest), kunnen we overgaan tot het daadwerkelijk schrijven van scripts voor taken.

Wij schrijven scripts

Misschien was er eens, in een melkwegstelsel ver, ver weg, het bouwen van projecten (inclusief die op .net) vanaf de opdrachtregel lastig. Nu kun je het project bouwen, testen en publiceren in 3 teams:

dotnet build
dotnet test
dotnet pack

Natuurlijk zijn er enkele nuances waardoor we de commando's enigszins zullen compliceren.

We willen een release-build, geen debug-build, dus voegen we toe aan elke opdracht -c Release
Bij het testen willen we codedekkingsgegevens verzamelen, dus we moeten een dekkingsanalysator opnemen in de testbibliotheken:
1. Voeg het pakket toe aan alle testbibliotheken coverlet.msbuild: dotnet add package coverlet.msbuild uit de projectmap
2. Voeg toe aan de testrun-opdracht /p:CollectCoverage=true
3. Voeg een sleutel toe aan de testtaakconfiguratie om dekkingsresultaten te krijgen (zie hieronder)
Stel bij het inpakken van de code in nuget-pakketten de uitvoerdirectory voor de pakketten in: -o .

Gegevens over codedekking verzamelen

Na het uitvoeren van de tests voeren Coverlet-afdrukken statistieken uit naar de console:

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

Met GitLab kun je een reguliere expressie specificeren om statistieken te krijgen, die vervolgens in de vorm van een badge kunnen worden verkregen. De reguliere expressie wordt gespecificeerd in de taakinstellingen met de sleutel coverage; de expressie moet een capture-groep bevatten, waarvan de waarde wordt doorgegeven aan de badge:

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

Hier krijgen we statistieken van een lijn met totale lijndekking.

Publiceer pakketten en documentatie

Beide acties zijn gepland voor de laatste fase van de pijplijn - sinds de montage en tests zijn geslaagd, kunnen we onze ontwikkelingen met de wereld delen.

Overweeg eerst om naar de pakketbron te publiceren:

Als het project geen nuget-configuratiebestand heeft (nuget.config), maak een nieuwe aan: dotnet new nugetconfig

Waarvoor: de afbeelding heeft mogelijk geen schrijftoegang tot globale (gebruiker en machine) configuraties. Om geen fouten op te vangen, maken we gewoon een nieuwe lokale configuratie en werken we ermee.
Laten we een nieuwe pakketbron toevoegen aan de lokale configuratie: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - lokale bronnaam, niet kritisch
2. url - URL van de bron uit de fase "Rekeningen voorbereiden", pagina 6
3. organization - organisatienaam in Azure DevOps
4. gitlab variable - de naam van de variabele met het toegangstoken toegevoegd aan GitLab ("Accounts voorbereiden", p. 11). Uiteraard in het formaat $variableName
5. -StorePasswordInClearText - een hack om de fout toegang geweigerd te omzeilen (Ik ben niet de eerste die op deze hark stapt)
6. Bij fouten kan het handig zijn om toe te voegen -verbosity detailed
Het pakket naar de bron sturen: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. We sturen alle pakketten vanuit de huidige directory, dus *.nupkg.
2. name - uit de bovenstaande stap.
3. key - elke regel. In Azure DevOps, in het venster Verbinden met feed, is het voorbeeld altijd de lijn az.
4. -skipduplicate - wanneer u een reeds bestaand pakket probeert te verzenden zonder deze sleutel, zal de bron een fout retourneren 409 Conflict; met de toets wordt het verzenden overgeslagen.

Laten we nu het maken van documentatie instellen:

Eerst initialiseren we in de repository, in de master branch, het docfx project. Voer hiervoor de opdracht uit vanaf de root docfx init en stel interactief de belangrijkste parameters in voor bouwdocumentatie. Gedetailleerde beschrijving van de minimale projectopstelling hier.
1. Bij het configureren is het belangrijk om de uitvoerdirectory op te geven ..public - GitLab neemt standaard de inhoud van de openbare map in de root van de repository als bron voor Pages. Omdat het project bevindt zich in een map die is genest in de repository - voeg een uitvoer toe aan het niveau hoger in het pad.
Laten we de wijzigingen naar GitLab pushen.
Voeg een taak toe aan de pijplijnconfiguratie pages (gereserveerd woord voor sitepublicatietaken in GitLab Pages):
1. Script:
  1. nuget install docfx.console -version 2.51.0 - installeer docfx; de versie wordt gespecificeerd om ervoor te zorgen dat de installatiepaden van het pakket correct zijn.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - documentatie verzamelen
2. Knooppuntartefacten:

pages:
  # snip
  artifacts:
    paths:
      - public

Lyrische uitweiding over docfx

Voorheen specificeerde ik bij het opzetten van een project de codebron voor de documentatie als een oplossingsbestand. Het grootste nadeel is dat er ook documentatie wordt gemaakt voor testprojecten. Als dit niet nodig is, kunt u deze waarde instellen op het knooppunt metadata.src:

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

metadata.src.src: "../" - we gaan een niveau hoger ten opzichte van de locatie docfx.json, omdat in patronen werkt het doorzoeken van de mappenboom niet.
metadata.src.files: ["**/*.csproj"] - een globaal patroon, we verzamelen alle C#-projecten uit alle mappen.
metadata.src.exclude: ["*.tests*/**"] - globaal patroon, alles uitsluiten van mappen met .tests In de titel

Subtotaal

Zo'n eenvoudige configuratie kan in slechts een half uur en een paar kopjes koffie worden gemaakt, waarmee u kunt controleren of de code is gebouwd en de tests zijn geslaagd, een nieuw pakket kunt bouwen, de documentatie kunt bijwerken en het oog kunt strelen met mooie badges in de README van het project bij elk samenvoegverzoek en verzending naar de master.

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

Over kentekens gesproken

Door hen is tenslotte alles begonnen!

Badges met pijplijnstatussen en codedekking zijn beschikbaar in GitLab in de CI/CD-instellingen in het Gtntral-pijplijnenblok:

Ik heb een badge gemaakt met een link naar de documentatie op het platform schilden.io - alles is daar vrij eenvoudig, u kunt uw eigen badge maken en deze op verzoek ontvangen.

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

Met Azure DevOps Artifacts kunt u ook badges maken voor pakketten met de nieuwste versie. Om dit te doen, moet u in de bron op de Azure DevOps-site klikken op Badge maken voor het geselecteerde pakket en de markdown-opmaak kopiëren:

Schoonheid toevoegen

Gemeenschappelijke configuratiefragmenten markeren

Tijdens het schrijven van de configuratie en het doorzoeken van de documentatie kwam ik een interessant kenmerk van YAML tegen: het hergebruiken van fragmenten.

Zoals je kunt zien aan de taakinstellingen, hebben ze allemaal de tag nodig windows bij de runner en worden geactiveerd wanneer een samenvoegverzoek naar de master/aangemaakt wordt verzonden (behalve documentatie). Laten we dit toevoegen aan het fragment dat we zullen hergebruiken:

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

En nu kunnen we het eerder in de taakbeschrijving gedeclareerde fragment invoegen:

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

Fragmentnamen moeten met een punt beginnen, om niet als een taak geïnterpreteerd te worden.

Versiebeheer van pakketten

Bij het maken van een pakket controleert de compiler de opdrachtregelschakelaars en bij afwezigheid de projectbestanden; wanneer het een Version-knooppunt vindt, neemt het zijn waarde als de versie van het pakket dat wordt gebouwd. Het blijkt dat om een pakket met een nieuwe versie te bouwen, je het moet bijwerken in het projectbestand of het moet doorgeven als een opdrachtregelargument.

Laten we nog een verlanglijst toevoegen - laat de kleine twee cijfers in de versie het jaar en de builddatum van het pakket zijn, en voeg prerelease-versies toe. U kunt deze gegevens natuurlijk aan het projectbestand toevoegen en voor elke indiening controleren - maar u kunt dit ook in de pijplijn doen door de pakketversie uit de context te halen en deze via de opdrachtregelargument door te geven.

Laten we afspreken dat als het commit-bericht een regel als release (v./ver./version) <version number> (rev./revision <revision>)?, dan nemen we de versie van het pakket van deze regel, vullen deze aan met de huidige datum en geven deze als argument door aan het commando dotnet pack. Bij het uitblijven van een lijn halen we het pakket simpelweg niet op.

Het volgende script 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

Een script toevoegen aan een taak pack and deploy job en observeer de samenstelling van pakketten strikt in de aanwezigheid van een bepaalde string in het commit-bericht.

In totaal

Na ongeveer een half uur of een uur besteed te hebben aan het schrijven van de configuratie, het debuggen in de lokale powershell en mogelijk een paar mislukte lanceringen, kregen we een eenvoudige configuratie voor het automatiseren van routinetaken.

Natuurlijk is GitLab CI/CD veel uitgebreider en veelzijdiger dan het lijkt na het lezen van deze handleiding - dat is helemaal niet waar. Daar zelfs Auto DevOps weltoelaten

automatisch uw applicaties detecteren, bouwen, testen, implementeren en bewaken

Nu zijn de plannen om een pijplijn te configureren voor het implementeren van applicaties naar Azure, met behulp van Pulumi en het automatisch bepalen van de doelomgeving, wat in het volgende artikel zal worden behandeld.

Bron: www.habr.com

Een gids voor CI/CD in GitLab voor de (bijna) absolute beginner