ProHoster > Blog > Administratioun > E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

Oder wéi Dir schéi Badge fir Äre Projet kritt an engem Owend vun einfacher Kodéierung

Wahrscheinlech, all Entwéckler, deen iergendwann op d'mannst ee Hausdéierprojet huet, huet e Jucken iwwer schéi Schëlder mat Statusen, Codeofdeckung, Package Versiounen am Nuget ... An dëst Jucken huet mech gefouert fir dësen Artikel ze schreiwen. Als Virbereedung fir et ze schreiwen, krut ech dës Schéinheet an engem vu menge Projeten:

E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

Dësen Artikel wäert Iech duerch d'Basis-Setup vun der kontinuéierlecher Integratioun a Liwwerung fir en .Net Core-Klassbibliothéiksprojet am GitLab goen, Dokumentatioun op GitLab Pages publizéieren, a gebaute Packagen op e private Feed an Azure DevOps drécken.

VS Code gouf als Entwécklungsëmfeld mat der Extensioun benotzt GitLab Workflow (fir d'Astellungsdatei direkt aus der Entwécklungsëmfeld ze validéieren).

Kuerz Aféierung

CD - ass et wann Dir just gedréckt hutt, an alles ass schonn op de Client gefall?

Wat ass CI / CD a firwat Dir et braucht - Dir kënnt et einfach google. Fannt komplett Dokumentatioun iwwer d'Konfiguratioun vu Pipelines am GitLab och einfach. Hei wäert ech kuerz an, wa méiglech, ouni Mängel de Prozess vum System aus engem Vugel Vue beschreiwen:

  • den Entwéckler schéckt en Engagement an de Repository, erstellt eng Fusiounsufro iwwer de Site, oder op eng aner Manéier explizit oder implizit d'Pipeline ufänkt,
  • all Aufgabe ginn aus der Konfiguratioun ausgewielt, d'Konditioune vun deenen et erlaabt datt se am bestëmmte Kontext lancéiert ginn,
  • Aufgaben sinn no hiren Etappe organiséiert,
  • Etappe ginn am Tour duerchgefouert - d.h. parallel all Aufgaben vun dëser Etapp sinn ofgeschloss,
  • wann d'Bühn fällt (dh op d'mannst eng vun den Aufgaben vun der Bühn feelt), stoppt d'Pipeline (bal ëmmer),
  • wann all Etappe erfollegräich ofgeschloss sinn, gëtt d'Pipeline als erfollegräich ugesinn.

Sou hu mir:

  • Pipeline - eng Rei vun Aufgaben, organiséiert an Etappen, an deenen Dir kënnt bauen, testen, packen Code, e fäerdeg Build op e Cloud Service ofsetzen, asw.,
  • Etapp (Etapp) - Pipeline Organisatioun Eenheet, enthält 1+ Aufgab,
  • Aufgab (Aarbecht) ass eng Eenheet vun der Aarbecht an der Pipeline. Et besteet aus engem Skript (obligatoresch), Startbedéngungen, Astellunge fir Artefakte ze publizéieren / Cache, a vill méi.

Deementspriechend kënnt d'Aufgab beim Astelle vun CI / CD erof op eng Rei vun Aufgaben ze kreéieren déi all déi néideg Aktiounen ëmsetzen fir Code an Artefakte ze bauen, ze testen an ze publizéieren.

Ier Dir ufänkt: firwat?

  • Firwat Gitlab?

Well wann et néideg gouf fir privat Repositories fir Hausdéierprojeten ze kreéieren, goufen se op GitHub bezuelt, an ech war giereg. D'Repositories si gratis ginn, awer bis elo ass dëst net genuch Grond fir mech op GitHub ze plënneren.

  • Firwat net Azure DevOps Pipelines?

Well do ass d'Astellung elementar - Wësse vun der Kommandozeil ass net emol erfuerderlech. Integratioun mat externen Git Ubidder - an e puer Klicks, Import vun SSH Schlësselen fir Verpflichtungen an de Repository ze schécken - och d'Pipeline ass einfach konfiguréiert och net vun enger Schabloun.

Startpositioun: wat Dir hutt a wat Dir wëllt

Mir hunn:

  • Repository am GitLab.

Mir wëllen:

  • automatesch Versammlung an Tester fir all Fusiounsufro,
  • Pakete fir all Fusiounsufro bauen an op de Master drécken, virausgesat datt et eng gewësse Zeil an der Verpflichtungsmeldung ass,
  • gebaut Packagen op e private Feed an Azure DevOps schécken,
  • Versammlung vun Dokumentatioun a Verëffentlechung op GitLab Säiten,
  • Schëlder! 11

Déi beschriwwe Ufuerderunge falen organesch op de folgende Pipelinemodell:

  • Etapp 1 - Assemblée
    • Mir sammelen de Code, publizéieren d'Ausgabdateien als Artefakt
  • Etapp 2 - Testen
    • Mir kréien Artefakte vun der Bauphase, lafen Tester, sammelen Code Ofdeckungsdaten
  • Etapp 3 - Soumissioun
    • Aufgab 1 - bauen den Nuget Package a schéckt et op Azure DevOps
    • Aufgab 2 - mir sammelen de Site vum xmldoc am Quellcode a publizéieren et op GitLab Säiten

Loosst eis ufänken!

Sammelen der Configuratioun

Preparéieren Konte

  1. Schafen e Kont an Microsoft sëlwer

  2. Géi op Azure DevOps

  3. Mir kreéieren en neie Projet

    1. Numm - iergendeen
    2. Visibilitéit - all
      E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

  4. Wann Dir op de Knäppchen erstellen klickt, gëtt de Projet erstallt an Dir gitt op seng Säit ëmgeleet. Op dëser Säit kënnt Dir onnéideg Funktiounen ausschalten andeems Dir op d'Projet Astellunge gitt (ënneschten Link an der Lëscht op der lénker Säit -> Iwwersiicht -> Azure DevOps Services Block)
    E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

  5. Gitt op Atrifacts, klickt Feed erstellen

    1. Gitt den Numm vun der Quell un
    2. Wielt Visibilitéit
    3. Auschecken Pakete vu gemeinsame ëffentleche Quellen enthalen, sou datt d'Quell net zu engem Dump Nuget Klon gëtt
      E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

  6. Klickt Connect to feed, wielt Visual Studio, kopéiert Quell aus dem Machine Setup Block
    E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

  7. Gitt op d'Kont Astellungen, wielt Personal Access Token
    E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

  8. Erstellt en neien Zougangstoken

    1. Numm - arbiträr
    2. Organisatioun - Aktuell
    3. Valabel fir maximal 1 Joer
    4. Ëmfang - Verpakung / Liesen & Schreiwen
      E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

  9. Kopéiert den erstallten Token - no der modal Fënster zougemaach ass, wäert de Wäert net disponibel sinn

  10. Gitt op d'Repository-Astellungen am GitLab, wielt d'CI / CD Astellungen
    E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

  11. Erweidert de Variablen Block, füügt en neien

    1. Numm - all ouni Plazen (gëtt an der Kommandoshell verfügbar)
    2. Wäert - Zougang Token vum Paragraph 9
    3. Wielt Mask Variabel
      E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

Dëst fäerdeg d'Pre-Configuratioun.

Preparéieren der Konfiguratioun Kader

Par défaut benotzt d'CI / CD Konfiguratioun am GitLab d'Datei .gitlab-ci.yml vun der Wuerzel vum Repository. Dir kënnt en arbiträre Wee fir dës Datei an de Repository-Astellunge setzen, awer an dësem Fall ass et net néideg.

Wéi Dir aus der Extensioun gesitt, enthält d'Datei eng Konfiguratioun am Format YAML. D'Dokumentatioun Detailer déi Schlësselen kënnen um Top Niveau vun der Konfiguratioun enthale sinn, an op jiddereng vun den nested Niveauen.

Als éischt, loosst eis e Link op d'Docker-Bild an der Konfiguratiounsdatei addéieren, an där d'Aufgaben ausgefouert ginn. Fir dëst fanne mir .Net Core Biller Säit op Docker Hub. d' GitHub et gëtt en detailléierte Guide iwwer wéi ee Bild fir verschidden Aufgaben ze wielen. E Bild mat .Net Core 3.1 ass gëeegent fir eis ze bauen, also fille sech fräi fir déi éischt Zeil an d'Konfiguratioun ze addéieren

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

Elo, wann d'Pipeline vum Microsoft Image Repository gestart gëtt, gëtt de spezifizéierte Bild erofgelueden, an deem all Aufgaben aus der Konfiguratioun ausgefouert ginn.

Deen nächste Schrëtt ass derbäi Etapp's. Par défaut definéiert GitLab 5 Etappen:

  • .pre - bis op all Etappen duerchgefouert,
  • .post - no all Etappen duerchgefouert,
  • build - éischt no .pre Etapp,
  • test - zweet Phase,
  • deploy - déi drëtt Etapp.

Näischt verhënnert Iech awer ausdrécklech ze deklaréieren. D'Uerdnung an där d'Schrëtt opgezielt sinn, beaflosst d'Uerdnung an där se duerchgefouert ginn. Fir Vollständegkeet, loosst eis d'Konfiguratioun addéieren:

stages:
  - build
  - test
  - deploy

Fir Debugging mécht et Sënn fir Informatioun iwwer d'Ëmwelt ze kréien an där d'Aufgaben ausgefouert ginn. Loosst eis e globale Set vu Befehle addéieren, déi virun all Aufgab ausgefouert ginn before_script:

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

Et bleift op d'mannst eng Aufgab ze addéieren, sou datt wann d'Verpflichtungen geschéckt ginn, d'Pipeline fänkt un. Fir elo, loosst eis eng eidel Aufgab derbäi fir ze demonstréieren:

dummy job:
  script:
    - echo ok

Mir starten d'Validatioun, mir kréien e Message datt alles gutt ass, mir engagéieren, mir drécken, mir kucken d'Resultater um Site ... A mir kréien e Skriptfehler - bash: .PSVersion: command not found. wtf?

Alles ass logesch - Par défaut, Leefer (verantwortlech fir d'Ausféierung vun Task Scripten a geliwwert vu GitLab) benotzen bash Kommandoen auszeféieren. Dir kënnt dëst fixéieren andeems Dir explizit an der Taskbeschreiwung spezifizéiert wéi eng Tags den ausféierende Pipeline Runner soll hunn:

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

Super! D'Pipeline leeft elo.

En opmierksam Lieser, deen déi uginn Schrëtt widderholl huet, bemierkt datt d'Aufgab an der Bühn ofgeschloss gouf test, obwuel mir d'Bühn net uginn hunn. Wéi Dir kéint roden test ass de Standard Schrëtt.

Loosst eis weiderhin d'Konfiguratiounsskelett erstellen andeems Dir all déi uewe beschriwwen Aufgaben bäidréit:

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

Mir hunn eng net besonnesch funktionell, awer trotzdem korrekt Pipeline.

Ausléiser opsetzen

Wéinst der Tatsaach datt keng Ausléiserfilter fir eng vun den Aufgaben spezifizéiert sinn, wäert d'Pipeline voll ass ausgefouert ginn all Kéier wann e Verpflichtung an de Repository gedréckt gëtt. Well dëst net dat gewënschte Verhalen am Allgemengen ass, wäerte mir Ausléiserfilter fir Aufgaben opsetzen.

Filtere kënnen an zwee Formater konfiguréiert ginn: nëmmen / ausser и Regelen. kuerz, only/except erlaabt Iech Filteren duerch Ausléiser ze konfiguréieren (merge_request, zum Beispill - setzt d'Aufgab auszeféieren fir all Kéier wann eng Pull-Ufro erstallt gëtt an all Kéier Verpflichtungen an d'Branche geschéckt ginn, déi d'Quell an der Fusiounsufro ass) a Branchennimm (och mat reguläre Ausdréck); rules erlaabt Iech eng Rei vu Konditiounen ze personaliséieren an, optional, d'Task Ausféierungskonditioun z'änneren ofhängeg vum Erfolleg vu fréiere Aufgaben (when an GitLab CI/CD).

Loosst eis eng Rei vun Ufuerderunge erënneren - Assemblée an Testen nëmme fir Fusiounsufro, Verpakung a Schécken op Azure DevOps - fir Fusiounsufro an Drécker op de Master, Dokumentatiounsgeneratioun - fir Drécken op de Master.

Als éischt, loosst eis d'Code Build Task opsetzen andeems Dir eng Regel bäidréit déi nëmmen op Fusiounsufro brennt:

build job:
  # snip
  only:
    - merge_request

Loosst eis elo d'Verpakungsaufgab opsetzen fir op d'Fusiounsufro ze brennen an d'Verpflichtungen un de Master ze addéieren:

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

Wéi Dir kënnt gesinn, ass alles einfach an einfach.

Dir kënnt och d'Aufgab setzen fir nëmmen ze brennen wann eng Fusiounsufro mat engem spezifeschen Zil- oder Quellzweig erstallt gëtt:

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

Ënner Bedingungen kënnt Dir benotzen Variabelen hei opgezielt; Regelen rules inkompatibel mat de Regelen only/except.

Artifact Saving konfiguréieren

Während enger Aufgab build job mir wäerten Artefakte bauen déi a spéider Aufgaben erëmbenotzt kënne ginn. Fir dëst ze maachen, musst Dir d'Weeër an d'Taskkonfiguratioun addéieren, d'Dateien, laanscht déi Dir an de folgenden Aufgaben späichere musst a weiderbenotzen, op de Schlëssel artifacts:

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

Weeër ënnerstëtzen Wildcards, wat se definitiv méi einfach mécht ze setzen.

Wann eng Aufgab Artefakte erstellt, da wäert all spéider Aufgab fäeg sinn op hinnen zouzegräifen - si wäerte laanscht déiselwecht Weeër relativ zu der Repositoryroot lokaliséiert ginn, déi aus der ursprénglecher Aufgab gesammelt goufen. Artefakte sinn och verfügbar fir erofzelueden um Site.

Elo datt mir e Konfiguratiounskader fäerdeg hunn (a getest), kënne mir weidergoen fir Scripte fir Aufgaben ze schreiwen.

Mir schreiwen Scripten

Vläicht, eemol, an enger Galaxis wäit, wäit ewech, Bauprojeten (och déi op .net) vun der Kommandozeil war e Péng. Elo kënnt Dir de Projet an 3 Teams bauen, testen a verëffentlechen:

dotnet build
dotnet test
dotnet pack

Natierlech ginn et e puer Nuancen, duerch déi mir d'Befehle e bësse komplizéiere wäerten.

  1. Mir wëllen e Release Build, net e Debug Build, also addéiere mir un all Kommando -c Release
  2. Wann Dir testen, wëlle mir Code Ofdeckungsdaten sammelen, also musse mir en Ofdeckungsanalysator an den Testbibliothéiken enthalen:
    1. Füügt de Package un all Testbibliothéiken coverlet.msbuild: dotnet add package coverlet.msbuild vum Projet Dossier
    2. Füügt de Kommando vum Testrun /p:CollectCoverage=true
    3. Füügt e Schlëssel fir d'Testtaskkonfiguratioun fir Ofdeckungsresultater ze kréien (kuckt hei ënnen)
  3. Wann Dir de Code an Nuget Packagen packt, set den Ausgangsverzeechnes fir d'Packagen: -o .

Sammelt Code Ofdeckungsdaten

Nodeems Dir d'Tester ausgefouert hutt, dréckt Coverlet Statistiken op d'Konsole aus:

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 erlaabt Iech e reegelméissegen Ausdrock ze spezifizéieren fir Statistiken ze kréien, déi dann a Form vun engem Badge kritt kënne ginn. De reguläre Ausdrock gëtt an den Task Astellunge mat dem Schlëssel spezifizéiert coverage; den Ausdrock muss eng Capture-Grupp enthalen, dee Wäert vun deem un de Badge weidergeleet gëtt:

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

Hei kréie mer Statistike vun enger Linn mat total Linn Ofdeckung.

Verëffentlechen Packagen an Dokumentatioun

Béid Aktioune si fir déi lescht Etapp vun der Pipeline geplangt - well d'Versammlung an d'Tester passéiert sinn, kënne mir eis Entwécklungen mat der Welt deelen.

Als éischt, betruecht d'Verëffentlechung op d'Packagequell:

  1. Wann de Projet keng Nuget Konfiguratiounsdatei huet (nuget.config), erstellt en neien: dotnet new nugetconfig

    Fir wat: d'Bild kann net Schreiwen Zougang zu global (Benotzer a Maschinn) Configuratioun hunn. Fir keng Feeler ze fangen, kreéiere mir einfach eng nei lokal Konfiguratioun a schaffen domat.

  2. Loosst eis eng nei Packagequell an d'lokal Konfiguratioun addéieren: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
    1. name - lokal Quell Numm, net kritesch
    2. url - URL vun der Quell vun der Bühn "Konten virbereeden", S. 6
    3. organization - Organisatioun Numm an Azure DevOps
    4. gitlab variable - den Numm vun der Variabel mat dem Zougangstoken op GitLab bäigefüügt ("Konten virbereeden", S. 11). Natierlech, am Format $variableName
    5. -StorePasswordInClearText - en Hack fir den Zougang refuséiert Feeler z'entgoen (Ech sinn net deen Éischten, deen op dëser Rake trëppelt)
    6. Am Fall vu Feeler kann et nëtzlech sinn ze addéieren -verbosity detailed
  3. De Package un d'Quell schécken: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
    1. Mir schécken all Packagen aus dem aktuellen Verzeichnis, also *.nupkg.
    2. name - aus dem Schrëtt uewen.
    3. key - all Linn. An Azure DevOps, an der Connect to Feed Fënster, ass d'Beispill ëmmer d'Linn az.
    4. -skipduplicate - wann Dir probéiert e scho existente Package ouni dëse Schlëssel ze schécken, gëtt d'Quell e Feeler zréck 409 Conflict; mam Schlëssel gëtt d'Sendung iwwersprangen.

Loosst eis elo d'Schafung vun der Dokumentatioun opstellen:

  1. Als éischt, am Repository, an der Master Branche, initialiséieren mir den docfx Projet. Fir dëst ze maachen, lafen de Kommando aus der Root docfx init an interaktiv d'Schlësselparameter fir Baudokumentatioun setzen. Detailléiert Beschreiwung vum Minimum Projet Setup hei.
    1. Beim Konfiguratioun ass et wichteg den Ausgangsverzeechnes ze spezifizéieren ..public - GitLab hëlt als Standard den Inhalt vum ëffentlechen Dossier an der Root vum Repository als Quell fir Säiten. Well de Projet wäert an engem Dossier läit, deen am Repository nestéiert ass - füügt en Ausgang op den Niveau erop am Wee.
  2. Loosst eis d'Ännerungen op GitLab drécken.
  3. Füügt eng Aufgab un d'Pipelinekonfiguratioun pages (reservéiert Wuert fir Site Verëffentlechungsaufgaben op GitLab Säiten):
    1. Skript:
      1. nuget install docfx.console -version 2.51.0 - installéieren docfx; d'Versioun gëtt uginn fir sécherzestellen datt d'Packageinstallatiounsweeër korrekt sinn.
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - Dokumentatioun sammelen
    2. Node Artefakte:

pages:
  # snip
  artifacts:
    paths:
      - public

Lyresch Digression iwwer docfx

Virdrun, wann Dir e Projet opstellt, hunn ech de Codequell fir d'Dokumentatioun als Léisungsdatei uginn. Den Haaptnodeel ass datt d'Dokumentatioun och fir Testprojeten erstallt gëtt. Am Fall wou dëst net néideg ass, kënnt Dir esou e Wäert op den Node setzen metadata.src:

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

  1. metadata.src.src: "../" - mir ginn een Niveau erop par rapport zu der Plaz docfx.json, well a Musteren, d'Sich no der Verzeechnesbam funktionnéiert net.
  2. metadata.src.files: ["**/*.csproj"] - e globalt Muster, mir sammelen all C # Projeten aus all Verzeechnes.
  3. metadata.src.exclude: ["*.tests*/**"] - global Muster, ausgeschloss alles aus Classeure mat .tests Am Titel

Subtotal

Sou eng einfach Konfiguratioun kann an nëmmen eng hallef Stonn an e puer Taass Kaffi erstallt ginn, wat Iech erlaabt ze kontrolléieren ob de Code gebaut ass an d'Tester passéieren, en neie Package bauen, d'Dokumentatioun aktualiséieren an d'Ae mat schéinen Aen gefalen. Badges an der README vum Projet mat all Fusiounsufro an dem Master schécken.

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

Apropos Badges

Wéinst hinnen war schliisslech alles ugefaangen!

Badges mat Pipeline Statusen a Code Ofdeckung sinn am GitLab an den CI / CD Astellungen am Gtntral Pipelines Block verfügbar:

E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

Ech hunn e Badge mat engem Link op d'Dokumentatioun op der Plattform erstallt Schëlder.io - alles ass ganz einfach do, Dir kënnt Ären eegene Badge erstellen an et mat enger Ufro kréien.

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

E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

Azure DevOps Artifacts erlaabt Iech och Badge fir Packagen mat der leschter Versioun ze kreéieren. Fir dëst ze maachen, an der Quell op der Azure DevOps Site, musst Dir op Erstellt Badge fir de gewielte Package klickt a kopéiert de Markdown Markup:

E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

E Guide fir CI / CD am GitLab fir den (bal) absoluten Ufänger

Schéinheet dobäizemaachen

Highlighting Common Configuration Fragments

Wärend d'Konfiguratioun geschriwwen an d'Dokumentatioun gesicht hunn, sinn ech op eng interessant Feature vu YAML begéint - Fragmenter erëmbenotzen.

Wéi Dir aus den Task Astellunge kënnt gesinn, erfuerderen se all den Tag windows um Leefer, a ginn ausgeléist wann eng Fusioun Ufro un de Meeschter geschéckt / geschaf (ausser Dokumentatioun). Loosst eis dëst zum Fragment addéieren dat mir nei benotzen:

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

An elo kënne mir de Fragment, deen virdru deklaréiert gouf, an der Taskbeschreiwung setzen:

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

Fragmentnimm mussen mat engem Punkt ufänken, fir net als Aufgab interpretéiert ze ginn.

Package Versioun

Wann Dir e Package erstellt, kontrolléiert de Compiler d'Kommandozeilschalter, an an hirer Verontreiung, d'Projetdateien; wann et e Version Node fënnt, hëlt et säi Wäert als Versioun vum Package dat gebaut gëtt. Et stellt sech eraus datt fir e Package mat enger neier Versioun ze bauen, musst Dir se entweder an der Projektdatei aktualiséieren oder als Kommandozeilargument weiderginn.

Loosst eis nach eng Wonschlëscht derbäi ginn - loosst déi kleng zwou Zuelen an der Versioun d'Joer sinn an de Baudatum vum Package, a füügt Prerelease Versiounen derbäi. Natierlech kënnt Dir dës Donnéeën an d'Projetdatei addéieren a virun all Soumissioun iwwerpréiwen - awer Dir kënnt et och an der Pipeline maachen, d'Packageversioun aus dem Kontext sammelen an et duerch d'Command Line Argument weiderginn.

Loosst eis d'accord sinn datt wann de Commit Message eng Zeil enthält wéi release (v./ver./version) <version number> (rev./revision <revision>)?, da wäerte mir d'Versioun vum Package vun dëser Linn huelen, ergänzen se mam aktuellen Datum a ginn et als Argument un de Kommando dotnet pack. Beim Fehlen vun enger Zeil, sammele mir de Pak einfach net.

De folgende Skript léist dëse 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

Füügt e Skript op eng Aufgab pack and deploy job an observéiert d'Versammlung vu Packagen strikt an der Präsenz vun enger bestëmmter String an der Verpflichtungsmeldung.

Total

Nodeems mir ongeféier eng hallef Stonn oder eng Stonn verbruecht hunn d'Konfiguratioun ze schreiwen, an der lokaler Powershell ze Debuggen an eventuell e puer net erfollegräich Starten, hu mir eng einfach Konfiguratioun fir Routine Aufgaben ze automatiséieren.

Natierlech ass GitLab CI / CD vill méi extensiv a villsäiteg wéi et schéngt nodeems Dir dëse Guide gelies hutt - dat stëmmt guer net. Do souguer Auto DevOps asserlaben

automatesch z'entdecken, bauen, testen, ofsetzen an iwwerwaachen Är Uwendungen

Elo sinn d'Pläng fir eng Pipeline ze konfiguréieren fir Uwendungen op Azure z'installéieren, Pulumi ze benotzen an automatesch d'Zilëmfeld ze bestëmmen, wat am nächsten Artikel ofgedeckt gëtt.

Source: will.com

Setzt e Commentaire