🥇Przewodnik po CI/CD w GitLabie dla (prawie) absolutnego nowicjusza

Lub jak zdobyć piękne odznaki dla swojego projektu w jeden wieczór łatwego kodowania

Chyba każdy programista, który ma przynajmniej jeden projekt pet ma w pewnym momencie ochotę na piękne odznaki ze statusami, pokryciem kodu, wersjami pakietów w nuget... I to swędzenie skłoniło mnie do napisania tego artykułu. Przygotowując się do jej napisania, w jednym z moich projektów trafiło na to cudo:

Ten artykuł przeprowadzi Cię przez podstawową konfigurację ciągłej integracji i dostarczania projektu biblioteki klas platformy .Net Core w usłudze GitLab, publikowania dokumentacji na stronach GitLab i wypychania zbudowanych pakietów do prywatnego źródła danych w usłudze Azure DevOps.

VS Code został użyty jako środowisko programistyczne z rozszerzeniem Przepływ pracy GitLab (do sprawdzania poprawności pliku ustawień bezpośrednio ze środowiska programistycznego).

Krótkie wprowadzenie

CD - czy to wtedy, gdy dopiero co pchałeś, a już wszystko spadło na klienta?

Co to jest CI/CD i do czego jest Ci potrzebny - możesz łatwo wygooglować. Znajdź pełną dokumentację dotyczącą konfigurowania potoków w GitLab też łatwe. Tutaj krótko iw miarę możliwości bez błędów opiszę proces działania systemu z lotu ptaka:

programista wysyła zatwierdzenie do repozytorium, tworzy żądanie scalenia za pośrednictwem serwisu, lub w inny sposób jawnie lub niejawnie uruchamia potok,
z konfiguracji wybierane są wszystkie zadania, których warunki pozwalają na ich uruchomienie w zadanym kontekście,
zadania są uporządkowane według ich etapów,
etapy realizowane są kolejno – tj. równolegle wszystkie zadania tego etapu są zakończone,
jeśli etap zakończy się niepowodzeniem (tj. co najmniej jedno z zadań etapu zakończy się niepowodzeniem), potok zatrzymuje się (prawie zawsze),
jeśli wszystkie etapy zakończą się pomyślnie, potok zostanie uznany za pomyślny.

Zatem mamy:

potok - zestaw zadań podzielonych na etapy, w których można zbudować, przetestować, spakować kod, wdrożyć gotową kompilację do usługi w chmurze itp.,
scena (etap) — jednostka organizacyjna potoku, zawiera 1+ zadanie,
zadanie (praca) to jednostka pracy w potoku. Składa się ze skryptu (obowiązkowego), warunków uruchamiania, ustawień publikowania/buforowania artefaktów i wielu innych.

W związku z tym zadanie podczas konfigurowania CI/CD sprowadza się do stworzenia zestawu zadań, które realizują wszystkie niezbędne działania do budowania, testowania i publikowania kodu i artefaktów.

Przed rozpoczęciem: dlaczego?

Dlaczego Gitlab?

Bo kiedy trzeba było tworzyć prywatne repozytoria dla domowych projektów, płacili im na GitHubie, a ja byłem chciwy. Repozytoria stały się darmowe, ale jak na razie nie jest to dla mnie wystarczający powód, aby przenieść się na GitHub.

Dlaczego nie Azure DevOps Pipelines?

Ponieważ tam ustawienie jest elementarne - znajomość wiersza poleceń nie jest nawet wymagana. Integracja z zewnętrznymi dostawcami git - za pomocą kilku kliknięć, import kluczy SSH w celu wysłania zatwierdzeń do repozytorium - potok można łatwo skonfigurować nawet bez szablonu.

Pozycja wyjściowa: co masz i czego chcesz

Mamy:

repozytorium w GitLabie.

Chcemy:

automatyczne składanie i testowanie dla każdego żądania scalania,
budowanie pakietów dla każdego żądania scalania i wypychanie do mastera, pod warunkiem, że w komunikacie zatwierdzenia znajduje się określona linia,
wysyłanie zbudowanych pakietów do prywatnego feeda w Azure DevOps,
montaż dokumentacji i publikacja w GitLab Pages,
odznaki!11

Opisane wymagania organicznie spadają na następujący model potoku:

Etap 1 - montaż
- Zbieramy kod, publikujemy pliki wyjściowe jako artefakty
Etap 2 - testowanie
- Pozyskujemy artefakty z etapu budowania, przeprowadzamy testy, zbieramy dane o pokryciu kodu
Etap 3 — Prześlij
- Zadanie 1 — Skompiluj pakiet nuget i wyślij go do usługi Azure DevOps
- Zadanie 2 - pobieramy stronę z xmldoc w kodzie źródłowym i publikujemy ją w GitLab Pages

Zacznijmy!

Zbieranie konfiguracji

Przygotowywanie kont

Załóż konto w Azure firmy Microsoft
Iść do Azure DevOps
Tworzymy nowy projekt
1. Imię - dowolne
2. Widoczność - dowolna
Po kliknięciu przycisku Utwórz projekt zostanie utworzony i zostaniesz przekierowany na jego stronę. Na tej stronie możesz wyłączyć niepotrzebne funkcje przechodząc do ustawień projektu (dolny link na liście po lewej -> Przegląd -> blok Azure DevOps Services)
Przejdź do Atrifacts, kliknij Utwórz kanał
1. Wprowadź nazwę źródła
2. Wybierz widoczność
3. Odznacz Dołącz pakiety z popularnych źródeł publicznych, aby źródło nie zmieniło się w zrzutowy klon nuget
Kliknij Connect to feed, wybierz Visual Studio, skopiuj Source z bloku Machine Setup
Przejdź do ustawień konta, wybierz Personal Access Token
Utwórz nowy token dostępu
1. Nazwa - dowolna
2. Organizacja — aktualna
3. Ważny maksymalnie 1 rok
4. Zakres — opakowanie/odczyt i zapis
Skopiuj utworzony token - po zamknięciu okna modalnego wartość będzie niedostępna
Przejdź do ustawień repozytorium w GitLab, wybierz ustawienia CI/CD
Rozwiń blok Zmienne, dodaj nowy
1. Nazwa - dowolna bez spacji (będzie dostępna w powłoce poleceń)
2. Wartość - token dostępu z paragrafu 9
3. Wybierz zmienną maski

To kończy konfigurację wstępną.

Przygotowanie frameworka konfiguracyjnego

Domyślnie konfiguracja CI/CD w GitLab korzysta z pliku .gitlab-ci.yml z katalogu głównego repozytorium. Możesz ustawić dowolną ścieżkę do tego pliku w ustawieniach repozytorium, ale w tym przypadku nie jest to konieczne.

Jak widać z rozszerzenia, plik zawiera konfigurację w formacie YAML. Dokumentacja wyszczególnia, które klucze mogą być zawarte na najwyższym poziomie konfiguracji i na każdym z poziomów zagnieżdżonych.

Najpierw dodajmy link do obrazu dockera w pliku konfiguracyjnym, w którym zadania będą wykonywane. Do tego znajdujemy Strona obrazów platformy .Net Core w usłudze Docker Hub, GitHub istnieje szczegółowy przewodnik, który obraz wybrać do różnych zadań. Obraz z .Net Core 3.1 jest odpowiedni dla nas do zbudowania, więc możesz dodać pierwszą linię do konfiguracji

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

Teraz, gdy potok zostanie uruchomiony z repozytorium obrazów Microsoft, zostanie pobrany określony obraz, w którym zostaną wykonane wszystkie zadania z konfiguracji.

Kolejnym krokiem jest dodanie etap'S. Domyślnie GitLab definiuje 5 etapów:

.pre - wykonywane do wszystkich etapów,
.post - wykonywane po wszystkich etapach,
build - pierwszy po .pre scena,
test - druga faza,
deploy - trzeci etap.

Nic jednak nie stoi na przeszkodzie, aby zadeklarować je wprost. Kolejność, w jakiej wymienione są kroki, wpływa na kolejność ich wykonywania. Dla kompletności dodajmy do konfiguracji:

stages:
  - build
  - test
  - deploy

Do debugowania sensowne jest uzyskanie informacji o środowisku, w którym wykonywane są zadania. Dodajmy globalny zestaw poleceń, które będą wykonywane przed każdym zadaniem z before_script:

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

Pozostaje dodać przynajmniej jedno zadanie, aby po wysłaniu zatwierdzeń potok się uruchomił. Na razie dodajmy puste zadanie, aby zademonstrować:

dummy job:
  script:
    - echo ok

Zaczynamy walidację, dostajemy komunikat, że wszystko jest w porządku, zatwierdzamy, wciskamy, patrzymy na wyniki na stronie… I dostajemy błąd skryptu – bash: .PSVersion: command not found. wtf?

Wszystko jest logiczne - domyślnie biegacze (odpowiedzialni za wykonywanie skryptów zadań i dostarczani przez GitLab) używają bash wykonywać polecenia. Możesz to naprawić, wyraźnie określając w opisie zadania, jakie tagi powinien mieć uruchamiający potok:

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

Świetnie! Rurociąg już działa.

Uważny czytelnik, po powtórzeniu wskazanych kroków, zauważy, że zadanie zostało wykonane na etapie test, chociaż nie określiliśmy etapu. Jak można się domyślić test jest krokiem domyślnym.

Kontynuujmy tworzenie szkieletu konfiguracji, dodając wszystkie zadania opisane powyżej:

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

Otrzymaliśmy niezbyt funkcjonalny, ale mimo to poprawny potok.

Konfigurowanie wyzwalaczy

Ze względu na fakt, że dla żadnego z zadań nie określono filtrów wyzwalaczy, potok będzie całkowite być wykonywane za każdym razem, gdy zatwierdzenie jest przesyłane do repozytorium. Ponieważ ogólnie nie jest to pożądane zachowanie, skonfigurujemy filtry wyzwalaczy dla zadań.

Filtry można skonfigurować w dwóch formatach: tylko/oprócz и reguły. Krótko, only/except pozwala konfigurować filtry według wyzwalaczy (merge_request, na przykład - ustawia zadanie do wykonania za każdym razem, gdy tworzone jest żądanie ściągnięcia i za każdym razem, gdy zatwierdzenia są wysyłane do gałęzi, która jest źródłem w żądaniu scalania) i nazwy gałęzi (w tym przy użyciu wyrażeń regularnych); rules pozwala dostosować zestaw warunków i opcjonalnie zmienić warunek wykonania zadania w zależności od powodzenia poprzednich zadań (when w GitLab CI/CD).

Przypomnijmy zestaw wymagań - asembler i testowanie tylko dla żądania scalania, pakowanie i wysyłanie do Azure DevOps - dla żądania scalania i wypychania do wzorca, generowanie dokumentacji - dla wypychania do wzorca.

Najpierw skonfigurujmy zadanie kompilacji kodu, dodając regułę, która uruchamia się tylko na żądanie scalania:

build job:
  # snip
  only:
    - merge_request

Teraz skonfigurujmy zadanie pakowania, aby uruchamiało żądanie scalania i dodajmy zatwierdzenia do wzorca:

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

Jak widać, wszystko jest proste i jednoznaczne.

Możesz także ustawić uruchamianie zadania tylko wtedy, gdy zostanie utworzone żądanie scalania z określoną gałęzią docelową lub źródłową:

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

W warunkach możesz użyć wymienione tutaj zmienne; zasady rules niezgodne z regulaminem only/except.

Konfigurowanie zapisywania artefaktów

Podczas zadania build job będziemy mieć artefakty budowania, które można ponownie wykorzystać w kolejnych zadaniach. Aby to zrobić, musisz dodać ścieżki do konfiguracji zadania, pliki, wzdłuż których będziesz musiał zapisać i ponownie użyć w kolejnych zadaniach, do klucza artifacts:

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

Ścieżki obsługują symbole wieloznaczne, co zdecydowanie ułatwia ich ustawianie.

Jeśli zadanie tworzy artefakty, to każde kolejne zadanie będzie miało do nich dostęp - będą one zlokalizowane wzdłuż tych samych ścieżek względem katalogu głównego repozytorium, które zostały zebrane z pierwotnego zadania. Artefakty są również dostępne do pobrania na stronie.

Teraz, gdy mamy gotowy framework konfiguracyjny (i przetestowany), możemy przystąpić do pisania skryptów zadań.

Piszemy skrypty

Być może kiedyś, w odległej galaktyce, budowanie projektów (w tym w .net) z wiersza poleceń było uciążliwe. Teraz możesz zbudować, przetestować i opublikować projekt w 3 zespołach:

dotnet build
dotnet test
dotnet pack

Oczywiście istnieją pewne niuanse, dzięki którym nieco skomplikujemy polecenia.

Chcemy wersji wydania, a nie kompilacji debugowania, więc dodajemy do każdego polecenia -c Release
Podczas testowania chcemy zbierać dane o pokryciu kodu, dlatego musimy uwzględnić analizator pokrycia w bibliotekach testowych:
1. Dodaj pakiet do wszystkich bibliotek testowych coverlet.msbuild: dotnet add package coverlet.msbuild z folderu projektu
2. Dodaj do polecenia uruchomienia testu /p:CollectCoverage=true
3. Dodaj klucz do konfiguracji zadania testowego, aby uzyskać wyniki pokrycia (patrz poniżej)
Pakując kod do pakietów nuget, ustaw katalog wyjściowy dla pakietów: -o .

Zbieranie danych o pokryciu kodu

Po uruchomieniu testów Coverlet drukuje na konsoli statystyki przebiegu:

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 umożliwia określenie wyrażenia regularnego w celu uzyskania statystyk, które następnie można uzyskać w postaci odznaki. Wyrażenie regularne określane jest w ustawieniach zadania za pomocą klawisza coverage; wyrażenie musi zawierać grupę przechwytywania, której wartość zostanie przekazana do plakietki:

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

Tutaj otrzymujemy statystyki z linii z całkowitym pokryciem linii.

Publikuj pakiety i dokumentację

Oba działania zaplanowane są na ostatni etap rurociągu – skoro montaż i testy minęły, możemy dzielić się naszymi opracowaniami ze światem.

Najpierw rozważ opublikowanie w źródle pakietu:

Jeśli projekt nie ma pliku konfiguracyjnego nuget (nuget.config), utwórz nowy: dotnet new nugetconfig

Czemu: obraz może nie mieć dostępu do zapisu w konfiguracjach globalnych (użytkownika i komputera). Aby nie wyłapać błędów, po prostu tworzymy nową konfigurację lokalną i pracujemy z nią.
Dodajmy nowe źródło pakietu do lokalnej konfiguracji: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - lokalna nazwa źródła, niekrytyczna
2. url - Adres URL źródła z etapu „Przygotowanie kont”, s. 6
3. organization — nazwa organizacji w usłudze Azure DevOps
4. gitlab variable - nazwa zmiennej z tokenem dostępu dodanym do GitLab („Przygotowanie kont”, s. 11). Oczywiście w formacie $variableName
5. -StorePasswordInClearText - hack, aby ominąć błąd odmowy dostępu (Nie jestem pierwszym, który nadepnął na tę grabie)
6. W przypadku błędów przydatne może być dodanie -verbosity detailed
Wysyłanie paczki do źródła: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Wysyłamy wszystkie paczki z bieżącego katalogu, więc *.nupkg.
2. name - od kroku powyżej.
3. key - dowolny wiersz. W usłudze Azure DevOps w oknie Połącz z kanałem informacyjnym przykładem jest zawsze wiersz az.
4. -skipduplicate - przy próbie wysłania już istniejącej paczki bez tego klucza źródło zwróci błąd 409 Conflict; klawiszem wysyłanie zostanie pominięte.

Teraz skonfigurujmy tworzenie dokumentacji:

Najpierw w repozytorium, w gałęzi master, inicjujemy projekt docfx. Aby to zrobić, uruchom polecenie z katalogu głównego docfx init i interaktywnie ustawiaj kluczowe parametry dokumentacji budowlanej. Szczegółowy opis minimalnej konfiguracji projektu tutaj.
1. Podczas konfigurowania ważne jest określenie katalogu wyjściowego ..public - GitLab domyślnie przyjmuje zawartość folderu publicznego w katalogu głównym repozytorium jako źródło dla Pages. Ponieważ projekt będzie zlokalizowany w folderze zagnieżdżonym w repozytorium - dodaj wyjście do poziomu wyżej w ścieżce.
Przenieśmy zmiany do GitLab.
Dodaj zadanie do konfiguracji potoku pages (słowo zastrzeżone dla zadań związanych z publikowaniem witryn w GitLab Pages):
1. Scenariusz:
  1. nuget install docfx.console -version 2.51.0 - zainstaluj docfx; wersja jest określona, aby upewnić się, że ścieżki instalacyjne pakietu są poprawne.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - zbieranie dokumentacji
2. Artefakty węzłów:

pages:
  # snip
  artifacts:
    paths:
      - public

Liryczna dygresja o docfx

Wcześniej podczas tworzenia projektu podawałem źródło kodu dla dokumentacji jako plik rozwiązania. Główną wadą jest to, że dokumentacja jest tworzona również dla projektów testowych. Jeśli nie jest to konieczne, możesz ustawić tę wartość dla pliku node metadata.src:

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

metadata.src.src: "../" - idziemy o jeden poziom wyżej względem lokacji docfx.json, ponieważ we wzorcach przeszukiwanie drzewa katalogów w górę nie działa.
metadata.src.files: ["**/*.csproj"] - globalny wzorzec, zbieramy wszystkie projekty C# ze wszystkich katalogów.
metadata.src.exclude: ["*.tests*/**"] - globalny wzorzec, wyklucz wszystko z folderów z .tests W tytule

Suma częściowa

Tak prostą konfigurację można stworzyć w zaledwie pół godziny i kilka filiżanek kawy, co pozwoli sprawdzić, czy kod jest zbudowany i testy wypadły pomyślnie, zbudować nowy pakiet, zaktualizować dokumentację i cieszyć oko pięknym odznaki w README projektu z każdym żądaniem scalenia i wysłaniem do mastera.

Końcowy plik .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

Mówiąc o odznakach

W końcu od nich wszystko się zaczęło!

Odznaki ze statusami potoków i pokryciem kodu są dostępne w GitLab w ustawieniach CI/CD w bloku potoków Gtntral:

Stworzyłem odznakę z linkiem do dokumentacji na platformie Tarcze.io - tam wszystko jest dość proste, możesz stworzyć własną odznakę i otrzymać ją na żądanie.

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

Usługa Azure DevOps Artifacts umożliwia także tworzenie odznak dla pakietów z najnowszą wersją. Aby to zrobić, w źródle na stronie Azure DevOps musisz kliknąć Utwórz plakietkę dla wybranego pakietu i skopiować znacznik przeceny:

Dodawanie piękna

Podświetlanie wspólnych fragmentów konfiguracji

Pisząc konfigurację i przeszukując dokumentację natknąłem się na ciekawą cechę YAML-a - ponowne wykorzystanie fragmentów.

Jak widać w ustawieniach zadania, wszystkie wymagają tagu windows w runnerze i są wyzwalane, gdy żądanie scalania jest wysyłane do głównego/utworzonego (z wyjątkiem dokumentacji). Dodajmy to do fragmentu, którego użyjemy ponownie:

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

I teraz możemy wstawić fragment zadeklarowany wcześniej w opisie zadania:

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

Nazwy fragmentów muszą zaczynać się od kropki, aby nie zostały zinterpretowane jako zadanie.

Wersjonowanie pakietów

Podczas tworzenia pakietu kompilator sprawdza przełączniki wiersza poleceń, aw przypadku ich braku pliki projektu; gdy znajdzie węzeł Version, przyjmuje jego wartość jako wersję budowanego pakietu. Okazuje się, że aby zbudować pakiet z nową wersją, trzeba albo zaktualizować go w pliku projektu, albo przekazać jako argument w wierszu poleceń.

Dodajmy jeszcze jedną listę życzeń - niech dwie mniejsze cyfry w wersji będą rokiem i datą kompilacji pakietu oraz dodajmy wersje przedpremierowe. Oczywiście możesz dodać te dane do pliku projektu i sprawdzić przed każdym przesłaniem - ale możesz też zrobić to w potoku, pobierając wersję pakietu z kontekstu i przekazując ją przez argument wiersza poleceń.

Umówmy się, że jeśli wiadomość zatwierdzenia zawiera linię podobną do release (v./ver./version) <version number> (rev./revision <revision>)?, to bierzemy wersję pakietu z tej linii, uzupełniamy o aktualną datę i przekazujemy jako argument do polecenia dotnet pack. W przypadku braku kolejki po prostu nie odbierzemy paczki.

Poniższy skrypt rozwiązuje ten 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

Dodanie skryptu do zadania pack and deploy job i obserwuj montaż pakietów ściśle w obecności podanego ciągu w komunikacie zatwierdzenia.

Razem

Po spędzeniu około pół godziny lub godziny na pisaniu konfiguracji, debugowaniu w lokalnym PowerShell i prawdopodobnie kilku nieudanych uruchomieniach, otrzymaliśmy prostą konfigurację do automatyzacji rutynowych zadań.

Oczywiście GitLab CI/CD jest znacznie bardziej rozbudowany i wielopłaszczyznowy niż mogłoby się wydawać po przeczytaniu tego poradnika - to wcale nie jest prawda. Tam nawet Auto DevOps jestpozwalać

automatycznie wykrywaj, buduj, testuj, wdrażaj i monitoruj aplikacje

Teraz w planach jest skonfigurowanie potoku do wdrażania aplikacji na Azure, przy użyciu Pulumi i automatycznego określania środowiska docelowego, co zostanie omówione w następnym artykule.

Źródło: www.habr.com