🥇CI/CD üçün GitLab-da (demək olar ki) tam başlanğıc bələdçisi

Yaxşı bir axşam sadə kodlaşdırma ilə layihəniz üçün gözəl nişanlar necə əldə etməyi öyrənmək

Müəyyən bir an gəlir ki, hər bir proqramçının bir pet layihəsi olarsa, gözəl status nişanları, kod əhatəsi, nuget-dakı paket versiyaları haqqında bir cür narahatlıq yaranır. Bu narahatlıq məni bu məqaləni yazmağa məcbur etdi. Məqaləyə hazırlanarkən, layihələrimdən birində belə bir gözəlliyi əldə etdim:

Bu məqalədə, GitLab-da .Net Core üçün sinif kitabxanası layihəsi üçün davamlı inteqrasiya və davamlı çatdırılma üçün əsas konfiqurasiya, GitLab Pages-da sənədlərin yayımlanması və yığılmış paketlərin Azure DevOps-da özəl bir feed-ə göndərilməsi nəzərdən keçiriləcək.

İnkişaf mühiti olaraq VS Code + GitLab Workflow dən istifadə edilmişdir (konfiqurasiya faylını düzəliş mühitindən doğrulamaq üçün).

Qısa giriş

CI/CD - bu, siz pusha basdığınız zaman müştəri üçün işlərin düşməsi deməkdirmi?

CI/CD nədir və niyə istifadə olunur - bunu asanlıqla axtarıb tapa bilərsiniz. GitLab-da pipeline-ların konfiqurasiyası üçün tam sənəd tapmaq da çətin deyil.Burada, mümkün qədər dəqiqliklə sistemin işini quşun baxışı ilə izah edəcəyəm:

proqramçı repozitoriya bir commit göndərir, sayt vasitəsi ilə merge request yaradır, ya da başqa bir şəkildə açıq və ya gizli olaraq pipeline-i işə salır,
konfiqurasiyadan bu kontekstdə işə salmağa icazə verən bütün tapşırıqlar seçilir,
tapşırıqlar öz mərhələlərinə uyğun təşkil olunur,
mərhələlər bir-birinin ardınca icra edilir - yəni, eyni anda bu mərhələnin bütün tapşırıqları həyata keçirilir,
əgər mərhələ uğursuz olarsa (yəni, mərhələnin bir tapşırığı da uğursuz tamamlansa) - pipeline dayanır (demək olar ki, hər zaman),
əgər bütün mərhələlər uğurla tamamlanıbsa, pipeline uğurla tamamlanmış sayılır.

Beləliklə, nəticə:

pipeline - mərhələrdə təşkil edilmiş tapşırıqlar toplusudur ki, burada kodu yığmaq, test etmək, paketləmək, hazırlanan yığınları bulud xidmətinə yayımlamaq və s. edilə bilər.
mərhələ (stage) - pipeline-ın təşkilat vahididir, 1+ tapşırığı ehtiva edir,
tapşırıq (job) - pipeline-də iş vahididir. Skriptdən (mütləq), işə salma şərtlərindən, artefaktların yayılması/qorunması konfiqurasiyasından və daha çox şeydən ibarətdir.

Müvafiq olaraq, CI/CD-nin konfiqurasiyasında tapşırıq bütün zəruri hərəkətləri yerinə yetirən tapşırıqlar toplusunu yaratmağa yönəldilmişdir.

İlk növbədə: niyə?

Niyə GitLab?

Çünki pet layihələri üçün özəl repozitoriyalar yaratmaq ehtiyacı yarandıqda, GitHub-da pullu idilər və mən - qənaətcil biriyəm. Repo ücretsiz oldu, lakin bu hələ də GitHub-a köçmək üçün kifayət qədər bir səbəb deyil.

Niyə Azure DevOps Pipelines deyil?

Çünki burada tənzimləmə sadədir - hətta komanda xətti bilikləri tələb olunmur. Xarici git provayderləri ilə inteqrasiya bir neçə kliklə, SSH açarlarının rejissoru ilə depoya komit göndərmək üçün də mümkündür - pipeline şablondan asılı olmayaraq asanlıqla tənzimlənir.

Başlanğıc mövqeyi: nə var və nə istəyirik

Var:

GitLab-da depo.

İstəyirik:

hər bir merge request üçün avtomatik yığma və sınaq,
hər bir merge request və master-a itələmə üçün mesajda müəyyən bir sətir varsa, paketlərin yığılması,
yığılmış paketləri Azure DevOps-da privat feed-ə göndərmə,
sənədin yığılması və GitLab Pages-də dərc edilməsi,
badge-lər!11

Təsvir olunan tələblər aşağıdakı pipeline modelinə uyğun gəlir:

mərhələ 1 — yığım
- Kodu yığıb, çıxış fayllarını artefaktlar kimi dərc edirik
mərhələ 2 — sınaq
- Yığım mərhələsindən artefaktları alırıq, sınaqları keçiririk, kodun əhatəsini yığırıq
mərhələ 3 — göndərmə
- Tapşırıq 1 — nuget paketini yığırıq və Azure DevOps-a göndəririk
- Tapşırıq 2 — xmldoc-dan sayt yığırıq və GitLab Pages-də dərc edirik

Başlayaq!

Konfiqurasiyanı yığırıq

Hesabları hazırlayırıq

Microsoft Azure-da hesab yaradırıq Microsoft Azure
Keçirik Azure DevOps
Yeni layihə yaradırıq
1. Ad — istənilən
2. Görünürlük — istənilən
Create düyməsini basdıqda layihə yaradılacaq və onun səhifəsinə keçid ediləcək. Bu səhifədə lazımsız imkanları deaktiv edə bilərik, layihənin parametrlərinə keçərək (solda siyahının aşağısında olan link -> Overview -> Azure DevOps Services bloku)
Atrifacts-a keçirik, Create feed düyməsini basırıq
1. Mənbənin adını daxil edirik
2. Görünürlüyü seçirik
3. Qutu işarəsini silirik Common public sources-dan paketlər daxil et, beləliklə mənbə nuget kopyalarına çevrilmir
Feed-ə qoşuluruq, Visual Studio seçirik, Machine Setup blokundan Source-u kopyalayırıq
Hesabın parametrlərinə gedirik, Personal Access Token-i seçirik
Yeni giriş tokeni yaradırıq
1. Ad — istənilən
2. Təşkilat — cari
3. Vaxt sərhədi — maksimum 1 il
4. Sahə (scope) — Packaging/Read & Write
Yaradılan tokeni kopyalayırıq — modal pəncərəni bağladıqdan sonra dəyər əlçatmaz olacaq
GitLab-da depo parametrlərinə daxil oluruq, CI/CD parametrlərini seçirik
Variables blokunu genişləndirir, yenisini əlavə edirik
1. Ad — heç bir boşluqsuz istənilən (komanda xəttində əlçatan olacaq)
2. Dəyər — 9-cu p.q-dan giriş tokeni
3. Mask variable seçirik

Bu, ilkin tənzimləmə başa çatdı.

Konfiqurasiya çərçivəsini hazırlayırıq

GitLab-da CI/CD tənzimləməsi üçün standart olaraq .gitlab-ci.yml deponun kökündəki fayl istifadə olunur. Bu fayla tam yolu depo parametrlərində quraşdırmaq olar, amma bu halda bu tələb olunmur.

Gördüyünüz kimi, uzantıdan, faylda YAMLformatında konfiqurasiya mövcuddur. Dokumentasiyada, konfiqurasiyanın üst səviyyəsində və hər bir iç içə səviyyədə hansı açarların olacağı ətraflı təsvir edilib.

Əvvəlcə konfiqurasiya faylına tapşırıqların icra olunacağı docker görüntüsünün linkini əlavə edək. Bunun üçün tapırıq Docker Hub'da .Net Core görüntüleri səhifəsiAncaq GitHub hansının müxtəlif tapşırıqlar üçün necə seçiləcəyi ilə bağlı ətraflı bələdçi var. Bizim üçün .Net Core 3.1 ilə qurmaq üçün uyğun olacaq görüntünü əlavə edirik

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

İndi Microsoft görüntü deposundan istədiyimiz görüntü yüklənəcək və konfiqurasiyada bütün tapşırıqlar burada icra olunacaq.

Növbəti mərhələ — əlavə etməkdir stagemərhələlər. Əsasən, GitLab 5 mərhələ təyin edir:

.pre — bütün mərhələlərdən əvvəl icra olunur,
.post — bütün mərhələlərdən sonra icra olunur,
build — birincisi, .pre — ikinci mərhələ,
test — üçüncü mərhələ.
deploy Bununla belə, onları açıq şəkildə elan etməkdə heç bir maneə yoxdur. Mərhələlərin sıralaması, onların icra olunduğu sıraya təsir edir. Tamlığı üçün konfiqurasiyaya əlavə edəcəyik:

stages: - build - test - deploy

Debugging üçün, tapşırıqların icra olunduğu mühit haqqında məlumat əldə etmək məntiqlidir. Hər tapşırıqdan əvvəl icra olunacaq qlobal komandalar əlavə edək

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

İndi ən azı bir tapşırığı əlavə edək ki, commitlər göndərildikdə pipeline işə düşsün. İndilikcə, nümayiş üçün boş bir tapşırıq əlavə edək:

dummy job: script: - echo ok

Validasiyanı işə salırıq, hər şeyin yaxşı olduğunu bildiririk, commit edirik, push edirik, nəticələri veb saytda görürük... Və bir skript səhvi alırıq —

bash: .PSVersion: command not found . WTF?Bu, tamamilə məntiqlidir — default olaraq runner'lar (tapşırıq skriptlərinin icrası ilə məşğul olan və GitLab tərəfindən təmin olunan) istifadə edir

komandaların icrası üçün. Bunu düzəltmək üçün, tapşırıq təsvirində olan pipeline runner'ın hansı taglara sahib olmalı olduğunu açıq şəkildə göstərə bilərik: bash dummy job on windows: script: - echo ok tags: - windows

Əla! İndi pipeline icra olunur.

Diqqətli oxucu, göstərilən addımları təkrarlayaraq, tapşırığın

mərhələsində icra olunduğunu fərq edəcəkdir, biz mərhələ təyin etməmişdik. Müəyyən etmək mümkün olduğu kimi, testbu, default mərhələsidir. test Konfiqurasiya skeletini yaratmağa davam edərək, yuxarıda təsvir olunan bütün tapşırıqları əlavə edək:

build job: script: - echo "building..." tags: - windows stage: buildtest and cover job: script: - echo "running tests and coverage analysis..." tags: - windows stage: testpack and deploy job: script: - echo "packing and pushing to nuget..." tags: - windows stage: deploypages: script: - echo "creating docs..." tags: - windows stage: deploy

Xüsusilə funksional olmasa da, nədənsə düzgün olan bir pipeline aldıq.

Triggerlərin tənzimlənməsi

Heç bir tapşırıq üçün icra filtrləri təyin edilmədiyi üçün, pipeline hər dəfə repository'ə commit göndərildikdə icra olunacaq. Bu, ümumilikdə arzuolunmaz bir davranışdır, ona görə də tapşırıq üçün icra filtrlərini tənzimləyəcəyik.

Filtlər iki formatda təyin oluna bilər: tamamilə only/except

only/except only/except və rules. Qısaca, only/except trigerlərə görə filtr tənzimləməyə imkan verir (merge_request, məsələn — hər bir birləşmə sorğusu yaradıldıqda və birləşmə sorğusunda əsas olan budağa hər bir komit göndərildikdə tapşırıq icra etməyə tənzimləyir) və budaqların adlarına (o cümlədən, mütəmadi ifadələrdən istifadə etməklə); rules şərtlər dəstini tənzimləməyə imkan verir və, ehtimal ki, əvvəlki tapşırıqların müvəffəqiyyətinə asılı olaraq tapşırığın icra şərtini dəyişdirir (hansı halda GitLab CI/CD).

Tələb dəstini xatırlayaq — birləşmə sorğusu üçün yığma və test, Azure DevOps-a paket və göndərmə — birləşmə sorğusu və master-ə pushlar üçün, sənəd yaradıcılığı — master-ə pushlar üçün.

Əvvəlcə yalnız birləşmə sorğusu zamanı baş verən yığıma tapşırığını tənzimləyək:

build job:
  # snip
  only:
    - merge_request

İndi yalnız birləşmə sorğusu və master-ə komit əlavə edilərkən baş verəcək paketləmə tapşırığını tənzimləyək:

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

Göründüyü kimi, hər şey sadə və açıqdır.

Həmçinin, yalnız müəyyən bir hədəf və ya mənbə budağı ilə birləşmə sorğusu yaradıldıqda baş verəcək bir tapşırığı da tənzimləmək mümkündür:

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

Şərtlərdə bura daxil edilən dəyişənlərdən istifadə etmək mümkündür; qaydalar rules qaydalar ilə uyğun deyil only/except.

Artefaktların saxlanması tənzimlənməsi

Tapşırıq icra edilərkən build job bizim üçün yığma artefaktları yaradılacaq, hansı ki, sonrakı tapşırıqlarda yeniden istifadə oluna bilər. Bunun üçün tapşırığın konfiqurasiyasına saxlanacaq və sonrakı tapşırıqlarda istifadə olunacaq fayl yollarını əlavə etmək lazımdır, açar artifacts:

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

Yollar wildcards-i dəstəkləyir, bu da onların müəyyən edilməsini asanlaşdırır.

Əgər tapşırıq artefaktlar yaradırsa, onda hər bir sonrakı tapşırıq onlara çıxış əldə edə biləcək — onlar ilk tapşırıqdan yığılmış, depodanın kökündə eyni yollarla yerləşəcəklər. Artefaktlar həmçinin vebsayt üzərindən yükləmək üçün mövcuddur.

İndi, hazır (və təsdiq edilmiş) konfiqurasiya çərçivəmiz olduğuna görə, özündə tapşırıq skriptlərini yazmağa keçə bilərik.

Skriptlərin yazılması

Bəlkə də, çox-çox əvvəl, uzaq bir qalaktikada, komandadan yığılıb (o cümlədən .net-də) layihələr toplamaq çətinlik idi. İndi isə 3 komandada yığmaq, test etmək və layihəni yayımlamaq mümkündür:

dotnet build
dotnet test
dotnet pack

Təbii ki, komandaları bir az çətinləşdirəcək bəzi nüanslar var.

Biz reliz yazılışı, yoxsa debuq yazılışı istəyirik, ona görə də hər bir komandaya -c Release
Test edərkən biz kodun örtükləri haqqında məlumat toplamaq istəyirik, buna görə test kitabxanalarına örtük analizatorunu əlavə etmək lazım olacaq:
1. Bütün test kitabxanalarına paketi əlavə etmək lazımdır coverlet.msbuild: dotnet add package coverlet.msbuild layihə qovluğundan
2. Test iş başlatma ekibine ekleyelim /p:CollectCoverage=true
3. Test görevi yapılandırmasına sonuçların kapsama alanını almak için bir anahtar ekleyelim (aşağıya bakın)
NuGet paketlerini paketlerken paketler için çıkış dizinini tanımlayalım: -o .

Kapsama verilerini topluyoruz

Coverlet, testler çalıştırıldıktan sonra konsolda yürütme istatistiklerini görüntüler:

Kapsama sonucunu hesaplarken...
  Rapor üretiliyor 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Modül       | Satır  | Dallanma| Yöntem  |
+-------------+--------+--------+--------+
| proje 1     | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| proje 2     | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| proje 3     | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Satır  | Dallanma| Yöntem  |
+---------+--------+--------+--------+
| Toplam  | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Ortalama | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

GitLab, daha sonra bir rozet olarak alınabilecek istatistikleri elde etmek için bir düzenli ifade belirtmenize izin verir. Düzenli ifade, görev ayarlarında anahtar ile belirtilir coverage; ifadede, bu değerin rozet olarak geçirileceği bir kapsama grubu bulunmalıdır:

test ve cover görevi:
  # snip
  kapsama: \/|s*Toplamlar*|s*(d+[,.]d+%)\/

Burada, satır başına toplam kapsama ile ilgili bir dizeden istatistik alıyoruz.

Paketleri ve belgeleri yayımlıyoruz

Her iki işlem de pipeline'ın son aşamasına atandı - derleme ve testler geçti, artık çalışmaları dünya ile paylaşmanın zamanı geldi.

Öncelikle paket kaynaklarına yayımlamayı gözden geçirelim:

Proje, NuGet yapılandırma dosyası içeriyorsa (nuget.config), yeni bir tane oluşturacağız: dotnet new nugetconfig
Neden: Görüntüde, global (kullanıcı ve makine) yapılandırmalara yazma izni yasaklanmış olabilir. Hatalarla karşılaşmamak için, yeni yerel bir yapılandırma oluşturalım ve bununla çalışalım.
Yerel yapılandırmaya yeni bir paket kaynağı ekleyelim: nuget sources add -name -source -username -password -configfile nuget.config -StorePasswordInClearText
1. Lisenziya, inkişaf etdiricilər və versiya idarəetmə sisteminin məlumatlarının mövcudluğu — yerel kaynak adı, önemsiz
2. Bu tələbləri — 'Hesapları hazırlıyoruz' adımından kaynak URL'si, madde 6
3. organization — Azure DevOps'taki organizasyon adı
4. gitlab variable — GitLab'a eklenmiş erişim tokeninin adı ("Hesapları hazırlıyoruz", madde 11). Elbette, formatta $variableName
5. -StorePasswordInClearText — erişim reddi hatasını aşmak için bir hack (ilk ben bu tuzağa düşmedim)
6. Hatalar durumunda yararlı olabilecek bir ekleme yapmak iyi olabilir -verbosity detailed
Paketi kaynaklara yolluyoruz: nuget push -source -skipduplicate -apikey *.nupkg
1. Mevcut dizindeki tüm paketleri yolluyoruz, bu nedenle *.nupkg.
2. Lisenziya, inkişaf etdiricilər və versiya idarəetmə sisteminin məlumatlarının mövcudluğu — üstteki adımdan.
3. key — herhangi bir dize. Azure DevOps'taki Feed'e Bağlan penceresinde daima örnek olarak gösterilen bir dizedir az.
4. -skipduplicate — bu anahtar olmadan zaten mevcut bir paketi göndermeye çalıştığınızda kaynak hata döndürür 409 Conflict; anahtar ile gönderim atlanır.

Artık belge oluşturmayı düzenleyelim:

Başlamaq üçün, repository-də, master branch-da, docfx layihəsini initializasiya edirik. Bunun üçün kökdən aşağıdakı əmri icra etməliyik: docfx init və interaktiv rejimdə sənədlərin yığılması üçün əsas parametrləri təyin edirik. Layihənin minimal konfiqurasiyası ilə bağlı ətraflı izah: burada.
1. Konfiqurasiyayı qurarkən çıxış direktoriyasını göstərmək vacibdir: ..public — GitLab, varsayılan olaraq, repo kökündəki public qovluğunun məzmununu Pages üçün mənbə kimi götürür. Layihə repo daxilindəki alt qovluqda olacağı üçün — çıxış yoluna yuxarı səviyyəyə əlavə edirik.
Dəyişiklikləri GitLab-a göndəririk.
Pipeline konfiqurasiyasına bir vəzifə əlavə edəcəyik: pages (GitLab Pages-də saytların yayılması üçün ayrılmış söz):
1. Skripti:
  1. nuget install docfx.console -version 2.51.0 — docfx-i quraşdırır; versiya paketin quraşdırma yollarının düzgünlüyünü təmin etməyi məqsəd qoyur.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json — sənədləri yığırıq.
2. Artifakt node:

pages:
  # snip
  artifacts:
    paths:
      - public

docfx haqqında bir lirik kənar məsələ

Əvvəllər layihəni konfiqurasiya edərkən sənədlər üçün mənbəyi layihə faylı kimi göstərirdim. Əsas mənfi tərəfi — sənədlər test layihələri üçün də yaradılır. Bu lazım olmadığında, node-a aşağıdakı dəyəri təyin etmək olar: metadata.src:

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

metadata.src.src: "..\/" — yerləşməyə nisbətən yuxarı səviyyəyə çıxırıq docfx.json, çünki nümunələrdə direktoriyalar ağacında yuxarı axtarış işləmir.
metadata.src.files: ["**\/*.csproj"] — qlobal nümunə, bütün C# layihələrini bütün direktoriyalardan toplayırıq.
metadata.src.exclude: ["*.tests*\/**"] — qlobal nümunə, .tests olan qovluqlardan hər şeyi xaric edirik. .tests adında

Aralıq nəticə

Belə sadə bir konfiqurasiyanı bir saatdan az müddətdə və bir neçə fincan qəhvə ilə hazırlamaq mümkündür ki, bu da hər bir birləşmə sorğusunda və master-a göndərilmədə kodun yığılmasını və testlərin keçməsini, yeni paketin yığılmasını, sənədlərin yenilənməsini təmin edir və layihənin README-sində gözəl badge'lər təqdim edir.

Son .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+%)\/n  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

Əslində, badge’lər

Onlar üçün hər şey başladı!

Pipeline statusları və kod örtükleri ilə badge'lər GitLab-da CI/CD parametrlərində Gtntral pipelines bölməsində mövcuddur:

Dokumentasiya linki olan badge'i mən platformada yaratdım Shields.io — orada hər şey kifayət qədər sadədir, öz badge'inizi yarada bilər və onu sorğu ilə əldə edə bilərsiniz.

![Shields.io nümunəsi](https://img.shields.io/badge/custom-badge-blue)

Azure DevOps Artifacts da paketlər üçün aktual versiyanı göstərən badge'lər yaratmağa imkan verir. Bunun üçün Azure DevOps saytında seçdiyiniz paket üzərinə Create badge düyməsinə klikləmək və markdown formatını köçürmək lazımdır:

Gözəllik əlavə edirik

Ümumi konfiqurasiya parçalarını vurğulayırıq

Konfiqurasiya yazarkən və sənədlərdə axtarış edərkən, mən YAML-ın maraqlı bir xüsusiyyəti olan parça təkrar istifadəsinə rast gəldim.

Tapıldığınız iş parametrlərindən göründüyü kimi, onların hamısı windows runner-da bir tag olmasını tələb edir və master-a göndərilərkən/ birləşmə sorğusu yaradıldıqda işə düşür (sənədlər xaric). Bunu təkrar istifadə edəcəyimiz parçada əlavə edək:

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

İndi vəzifə təsvirində əvvəlki parçanı daxil edə bilərik:

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

Parçaların adları nöqtədən başlamalıdır ki, iş kimi interpretasiya olunmasın.

Paketlərin versiyalaşdırılması

Paket yaradılarkən, kompilyator əmrlərdən ibarət açarları yoxlayır, əgər yoxdur isə — layihə fayllarını; Version düyününü tapdıqda, onun dəyərini yaradılan paketin versiyası kimi götürür. Beləliklə, yeni versiyalı paket düzəltmək üçün, ya onu layihə faylında yeniləməli, ya da komanda sətrindəki arqument olaraq təqdim etməlisiniz.

Başqa bir istəyimizi əlavə edək — versiyanın son iki nömrəsi il və paketlərinin yığılma tarixi olsun və əvvəlki versiya növlərini əlavə edək. Bu məlumatları layihə faylında əlavə etmək və hər göndərmə öncəsi yoxlamaq əlbəttə mümkündür — amma bunu pipeline-də də etmək olar, paketin versiyasını kontekstdən yığaraq və komanda sətrindəki arqumentlə keçirmək.

Razılaşaq ki, əgər commit mesajında belə bir sətir varsa release (v./ver./version) (rev./revision )?, biz bu sətirdən paket versiyasını götürəcək, onu cari tarixlə tamamlayacaq və 'dotnet pack' komandası üçün arqument olaraq təqdim edəcəyik. . Sətir olmadıqda — paket yığmayacağıq.Bu vəzifəni aşağıdakı skript həll edir:

Skripti vəzifəyə əlavə edirik

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

pack and deploy job və commit mesajında müəyyən edilmiş sətir olduğunda, paket yığılmasını izləyirik. Konfiqurasiya yazmağa, lokaldakı powershell-də düzəliş etməyə və bəlkə də bir neçə uğursuz işə 30 dəqiqə - 1 saat vaxt sərf etdikdən sonra, rutin vəzifələrin avtomatlaşdırılması üçün sadə bir konfiqurasiya əldə etdik.

Nəticədə

Əlbəttə, GitLab CI/CD daha geniş və müxtəlifdir, oxuduğunuz bu dərsliyindən daha çoxdur —

bu tamamilə belə deyil bu düzgün deyilOrada hətta Auto DevOps var, tətbiqlərinizi

avtomatik olaraq aşkar etmək, qurmaq, sınaqdan keçirmək, yayımlamaq və izləmək

İndi planlarda - Azure-da tətbiqlərin yayımı üçün bir pipeline konfiqurasiya etmək, Pulumi istifadə edərək və hədəf mühitini avtomatik olaraq aşkar etmək var, bu növbəti yazıda işıqlandırılacaq.

Mənbə: habr.com