ProHoster > Blog > Pangangasiwa > Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

O kung paano makakuha ng magagandang badge para sa iyong proyekto sa isang gabi ng nakakarelaks na coding

Marahil, ang bawat developer na mayroong kahit isang pet project sa ilang mga punto ay may pangangati para sa magagandang badge na may mga status, code coverage, mga bersyon ng package sa nuget... At ang kati na ito ay humantong sa akin na isulat ang artikulong ito. Sa proseso ng paghahanda sa pagsulat nito, nakuha ko ang kagandahang ito sa isa sa aking mga proyekto:

Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

Sasaklawin ng artikulong ito ang pangunahing setup ng tuluy-tuloy na pagsasama at paghahatid para sa isang .Net Core class library project sa GitLab, pag-publish ng dokumentasyon sa GitLab Pages at pagpapadala ng mga nakolektang package sa isang pribadong feed sa Azure DevOps.

Ang VS Code na may extension ay ginamit bilang isang development environment Daloy ng Trabaho ng GitLab (upang mapatunayan ang file ng mga setting nang direkta mula sa kapaligiran ng pag-unlad).

Maikling panimula

Ang CD ay kapag itinulak mo lang, ngunit nawala na ang lahat ng kliyente?

Ano ang CI/CD at bakit ito kailangan? Madali mo itong i-google. Maghanap ng kumpletong dokumentasyon sa pag-set up ng mga pipeline sa GitLab madali din. Narito ako ay maikli at, kung maaari, nang walang mga bahid, ilalarawan ang proseso ng system mula sa isang view ng isang ibon:

  • nagpapadala ang developer ng commit sa repository, lumilikha ng kahilingan sa pagsasama sa pamamagitan ng website, o sa ilang iba pang paraan tahasan o implicit na inilulunsad ang pipeline,
  • mula sa pagsasaayos, ang lahat ng mga gawain ay pinipili kung saan ang mga kundisyon ay nagpapahintulot sa kanila na ilunsad sa isang partikular na konteksto,
  • ang mga gawain ay isinaayos ayon sa kanilang mga yugto,
  • ang mga yugto ay isinasagawa sa turn - i.e. kahilera lahat ng mga gawain sa yugtong ito ay nakumpleto,
  • kung nabigo ang isang yugto (ibig sabihin, hindi bababa sa isa sa mga gawain ng yugto ay nabigo) - huminto ang pipeline (halos palagi),
  • kung ang lahat ng mga yugto ay matagumpay na nakumpleto, ang pipeline ay itinuturing na matagumpay.

Kaya mayroon kaming:

  • Ang pipeline ay isang hanay ng mga gawain na nakaayos sa mga yugto kung saan maaari kang mag-assemble, subukan, code ng package, i-deploy ang natapos na pagpupulong sa isang cloud service, atbp.
  • yugto (yugto) - yunit ng organisasyon ng pipeline, naglalaman ng 1+ gawain,
  • gawain (trabaho) ay isang yunit ng trabaho sa isang pipeline. Binubuo ng isang script (kinakailangan), kundisyon ng paglunsad, mga setting para sa pag-publish/pag-cache ng mga artifact at marami pang iba.

Alinsunod dito, ang gawain kapag nagse-set up ng CI/CD ay bumaba sa paglikha ng isang hanay ng mga gawain na nagpapatupad ng lahat ng kinakailangang aksyon para sa pag-assemble, pagsubok at pag-publish ng code at mga artifact.

Bago tayo magsimula: bakit?

  • Bakit GitLab?

Dahil noong kailanganin na lumikha ng mga pribadong repositoryo para sa mga proyekto ng alagang hayop, binayaran sila sa GitHub, at ako ay sakim. Ang mga repository ay naging libre, ngunit sa ngayon ay hindi ito sapat na dahilan para lumipat ako sa GitHub.

  • Bakit hindi Azure DevOps Pipelines?

Dahil simple ang setup - hindi mo na kailangan ng kaalaman sa command line. Pagsasama sa mga panlabas na git provider - sa ilang mga pag-click, pag-import ng mga SSH key para sa pagpapadala ng mga commit sa repository - masyadong, ang pipeline ay madaling i-configure kahit na walang template.

Panimulang posisyon: kung ano ang mayroon ka at kung ano ang gusto mo

Mayroon kaming:

  • imbakan sa GitLab.

Gusto namin:

  • awtomatikong pagpupulong at pagsubok para sa bawat kahilingan sa pagsasama,
  • pagbuo ng mga pakete para sa bawat kahilingan sa pagsasanib at pagtutulak sa master, sa kondisyon na mayroong isang tiyak na linya sa commit message,
  • pagpapadala ng mga nakolektang pakete sa isang pribadong feed sa Azure DevOps,
  • pagpupulong ng dokumentasyon at publikasyon sa Mga Pahina ng GitLab,
  • mga badge!11

Ang mga inilarawang kinakailangan ay natural na akma sa sumusunod na modelo ng pipeline:

  • Stage 1 - pagpupulong
    • Kinokolekta namin ang code, ini-publish ang mga output file bilang mga artifact
  • Stage 2 - pagsubok
    • Nakatanggap kami ng mga artifact mula sa yugto ng pagbuo, nagpapatakbo ng mga pagsubok, nangongolekta ng data ng saklaw ng code
  • Stage 3 - pagpapadala
    • Gawain 1 - kolektahin ang nuget package at ipadala ito sa Azure DevOps
    • Gawain 2 - binubuo namin ang site mula sa xmldoc sa source code at i-publish ito sa Mga Pahina ng GitLab

Magsimula na tayo!

Pagtitipon ng pagsasaayos

Paghahanda ng mga account

  1. Gumawa ng account sa Microsoft Azure

  2. Pumunta sa Mga Azure DevOps

  3. Gumawa ng bagong proyekto

    1. Pangalan - anuman
    2. Visibility - anumang
      Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

  4. Kapag nag-click ka sa pindutan ng Lumikha, ang proyekto ay malilikha at ikaw ay dadalhin sa pahina nito. Sa pahinang ito maaari mong i-disable ang mga hindi kinakailangang feature sa pamamagitan ng pagpunta sa mga setting ng mga proyekto (ibabang link sa listahan sa kaliwa -> Pangkalahatang-ideya -> Azure DevOps Services block)
    Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

  5. Pumunta sa Atrifacts, i-click ang Gumawa ng feed

    1. Ilagay ang pangalan ng pinagmulan
    2. Piliin ang visibility
    3. Alisan ng check ang kahon Isama ang mga pakete mula sa mga karaniwang pampublikong mapagkukunanpara hindi maging basurahan ng nuget clone ang pinanggalingan
      Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

  6. I-click ang Connect to feed, piliin ang Visual Studio, kopyahin ang Source mula sa Machine Setup block
    Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

  7. Pumunta sa mga setting ng account, piliin ang Personal Access Token
    Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

  8. Gumawa ng bagong access token

    1. Pangalan - arbitraryo
    2. Organisasyon - kasalukuyan
    3. Panahon ng bisa: maximum na 1 taon
    4. Saklaw - Packaging/Read & Write
      Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

  9. Kopyahin ang ginawang token - pagkatapos isara ang modal window ang halaga ay hindi magagamit

  10. Pumunta sa mga setting ng repository sa GitLab, piliin ang mga setting ng CI/CD
    Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

  11. Palawakin ang block ng Variables at magdagdag ng bago

    1. Pangalan - anumang walang mga puwang (makukuha sa command shell)
    2. Ang value ay ang access token mula sa hakbang 9
    3. Piliin ang Mask variable
      Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

Kinukumpleto nito ang paunang pag-setup.

Paghahanda ng balangkas ng pagsasaayos

Bilang default, ang file na ginamit upang i-configure ang CI/CD sa GitLab ay .gitlab-ci.yml mula sa ugat ng repositoryo. Maaari mong i-configure ang isang pasadyang landas sa file na ito sa mga setting ng imbakan, ngunit sa kasong ito ay hindi ito kinakailangan.

Tulad ng makikita mula sa extension, ang file ay naglalaman ng configuration sa format YAML. Ang dokumentasyon ay naglalarawan nang detalyado kung anong mga susi ang maaaring nilalaman sa pinakamataas na antas ng configuration, at sa bawat isa sa mga nested na antas.

Una, idagdag natin sa configuration file ang isang link sa docker image kung saan isasagawa ang mga gawain. Upang gawin ito nahanap namin .Net Core na mga larawan na pahina sa Docker Hub. Sa GitHub Mayroong detalyadong gabay kung aling larawan ang pipiliin para sa iba't ibang gawain. Ang isang imahe na may .Net Core 3.1 ay angkop para sa amin upang bumuo, kaya huwag mag-atubiling idagdag ito bilang ang unang linya sa configuration

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

Ngayon, kapag sinimulan mo ang pipeline, ang tinukoy na imahe ay mada-download mula sa Microsoft image repository, kung saan ang lahat ng mga gawain mula sa configuration ay isasagawa.

Ang susunod na hakbang ay ang magdagdag yugto's. Bilang default, tinutukoy ng GitLab ang 5 yugto:

  • .pre - isinasagawa sa lahat ng mga yugto,
  • .post - gumanap pagkatapos ng lahat ng mga yugto,
  • build - una pagkatapos .pre yugto,
  • test - pangalawang yugto,
  • deploy - ikatlong yugto.

Gayunpaman, walang pumipigil sa iyo na ipahayag ang mga ito nang tahasan. Ang pagkakasunud-sunod kung saan nakalista ang mga hakbang ay nakakaapekto sa pagkakasunud-sunod kung saan nakumpleto ang mga ito. Para sa pagkakumpleto, idagdag natin sa configuration:

stages:
  - build
  - test
  - deploy

Para sa pag-debug, makatuwirang kumuha ng impormasyon tungkol sa kapaligiran kung saan isinasagawa ang mga gawain. Magdagdag tayo ng isang pandaigdigang hanay ng mga utos na isasagawa bago ang bawat gawain gamit before_script:

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

Nananatili itong magdagdag ng kahit isang gawain para kapag ipinadala ang mga commit, magsisimula ang pipeline. Sa ngayon, magdagdag tayo ng walang laman na gawain para sa pagpapakita:

dummy job:
  script:
    - echo ok

Sinimulan namin ang pagpapatunay, kumuha ng mensahe na maayos ang lahat, gumawa, itulak, tingnan ang mga resulta sa site... At nakakuha kami ng error sa script - bash: .PSVersion: command not found. WTF?

Ang lahat ay lohikal - bilang default, ang mga runner (responsable para sa pagpapatupad ng mga script ng gawain at ibinigay ng GitLab) ay gumagamit bash upang isagawa ang mga utos. Maaayos mo ito sa pamamagitan ng tahasang pagpapakita sa paglalarawan ng gawain kung anong mga tag ang dapat magkaroon ng nagpapatakbo ng pipeline runner:

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

Malaki! Ang pipeline ay tumatakbo na ngayon.

Ang isang matulungin na mambabasa, na inuulit ang mga hakbang na ito, ay mapapansin na ang gawain ay nakumpleto sa yugto test, bagaman hindi namin tinukoy ang yugto. Tulad ng maaari mong hulaan, test ay ang default na hakbang.

Ipagpatuloy natin ang paglikha ng configuration skeleton sa pamamagitan ng pagdaragdag ng lahat ng mga gawaing inilarawan sa itaas:

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

Nakuha namin ang isang hindi partikular na gumagana, ngunit gayunpaman tamang pipeline.

Pagse-set up ng mga trigger

Dahil sa ang katunayan na walang trigger filter ay tinukoy para sa alinman sa mga gawain, ang pipeline ay ganap naisakatuparan sa tuwing ipinapadala ang mga commit sa repositoryo. Dahil hindi ito ang gustong gawi sa pangkalahatan, iko-configure namin ang mga filter ng trigger para sa mga gawain.

Maaaring i-configure ang mga filter sa dalawang format: lamang/maliban ΠΈ patakaran. Sa madaling salita, only/except nagbibigay-daan sa iyo na i-configure ang mga filter sa pamamagitan ng mga trigger (merge_request, halimbawa - kino-configure ang gawain na isasagawa sa tuwing may gagawing kahilingan sa pagsasanib at sa tuwing ipapadala ang mga commit sa sangay na pinagmumulan ng kahilingan sa pagsasanib) at mga pangalan ng sangay (kabilang ang paggamit ng mga regular na expression); rules nagbibigay-daan sa iyo na i-customize ang isang hanay ng mga kundisyon at, opsyonal, baguhin ang kondisyon ng pagpapatupad ng gawain depende sa tagumpay ng mga nakaraang gawain (when sa GitLab CI/CD).

Alalahanin natin ang hanay ng mga kinakailangan - pagpupulong at pagsubok para lamang sa mga kahilingan sa pagsasanib, pag-iimpake at pagpapadala sa Azure DevOps - para sa mga kahilingan sa pagsasanib at pagtulak sa master, henerasyon ng dokumentasyon - para sa mga push sa master.

Una, mag-set up tayo ng isang gawain sa pagpupulong ng code sa pamamagitan ng pagdaragdag ng panuntunan sa pag-trigger na nagti-trigger lamang ng kahilingan sa pagsasama:

build job:
  # snip
  only:
    - merge_request

Ngayon, i-configure natin ang gawain sa packaging para mag-trigger ng kahilingan sa pagsasama at magdagdag ng mga commit sa master:

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

Tulad ng nakikita mo, ang lahat ay simple at prangka.

Maaari mo ring i-configure ang gawain upang ma-trigger lamang kung ang isang kahilingan sa pagsasama ay ginawa gamit ang isang partikular na target o pinagmulang sangay:

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

Sa mga kondisyon maaari itong magamit mga variable na nakalista dito; mga tuntunin rules hindi tugma sa mga patakaran only/except.

Pag-configure ng Artifact Saving

Habang tumatakbo ang gawain build job magkakaroon tayo ng mga build artifact na nilikha na maaaring magamit muli sa mga susunod na gawain. Upang gawin ito, kailangan mong magdagdag ng mga landas sa pagsasaayos ng gawain, mga file kasama na kung saan ay kailangang i-save at muling gamitin sa kasunod na mga gawain, sa susi artifacts:

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

Sinusuportahan ng mga path ang mga wildcard, na talagang nagpapadali sa mga ito na itakda.

Kung ang isang gawain ay lumilikha ng mga artifact, kung gayon ang bawat kasunod na gawain ay maa-access ang mga ito - sila ay matatagpuan sa parehong mga landas na nauugnay sa root ng repositoryo kung saan sila nakolekta mula sa orihinal na gawain. Ang mga artifact ay magagamit din para sa pag-download sa website.

Ngayon na mayroon na tayong configuration framework na handa (at na-verify), maaari na tayong magpatuloy sa aktwal na pagsulat ng mga script para sa mga gawain.

Nagsusulat kami ng mga script

Marahil, noong unang panahon, sa isang kalawakan na malayo, malayo, ang pagbuo ng mga proyekto (kabilang ang mga .net) mula sa command line ay masakit. Ngayon ay maaari mo nang tipunin, subukan at i-publish ang proyekto sa 3 koponan:

dotnet build
dotnet test
dotnet pack

Naturally, mayroong ilang mga nuances dahil sa kung saan medyo kumplikado namin ang mga utos.

  1. Gusto namin ng release, hindi ng debug, build, kaya nagdadagdag kami sa bawat command -c Release
  2. Kapag sinusubukan, gusto naming mangolekta ng data sa saklaw ng code, kaya kailangan naming ikonekta ang isang coverage analyzer sa mga library ng pagsubok:
    1. Dapat idagdag ang package sa lahat ng test library coverlet.msbuild: dotnet add package coverlet.msbuild mula sa folder ng proyekto
    2. Idagdag sa test launch command /p:CollectCoverage=true
    3. Magdagdag tayo ng susi sa pagsasaayos ng gawain sa pagsubok upang makakuha ng mga resulta ng saklaw (tingnan sa ibaba)
  3. Kapag nag-package ng code sa mga nuget na pakete, itatakda namin ang direktoryo ng output para sa mga pakete: -o .

Pagkolekta ng data ng saklaw ng code

Pagkatapos patakbuhin ang mga pagsubok, ipinapakita ng Coverlet ang mga istatistika ng paglulunsad sa 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% |
+---------+--------+--------+--------+

Binibigyang-daan ka ng GitLab na tumukoy ng isang regular na expression upang makakuha ng mga istatistika, na maaaring makuha sa anyo ng isang badge. Ang regular na expression ay tinukoy sa mga setting ng gawain na may susi coverage; ang expression ay dapat maglaman ng pangkat ng pagkuha, ang halaga nito ay ililipat sa badge:

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

Dito nakakakuha kami ng mga istatistika mula sa isang linya na may kabuuang saklaw ayon sa mga linya.

Nag-publish kami ng mga pakete at dokumentasyon

Mayroon kaming parehong mga aksyon na itinalaga sa huling yugto ng pipeline - dahil ang pagpupulong at mga pagsubok ay lumipas na, maaari naming ibahagi ang aming mga pag-unlad sa mundo.

Una, tingnan natin ang pag-publish sa pinagmulan ng package:

  1. Kung ang proyekto ay walang nuget configuration file (nuget.config), lumikha ng bago: dotnet new nugetconfig

    Para saan: Maaaring walang access sa pagsulat ang larawan sa mga pandaigdigang configuration (user at machine). Upang hindi makahuli ng mga error, gagawa lang kami ng bagong lokal na configuration at gagana dito.

  2. Magdagdag tayo ng bagong source ng package sa lokal na configuration: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
    1. name β€” lokal na pangalan ng pinagmulan, hindi mahalaga
    2. url β€” URL ng pinagmulan mula sa yugto ng β€œPaghahanda ng mga account,” hakbang 6
    3. organization - pangalan ng organisasyon sa Azure DevOps
    4. gitlab variable β€” ang pangalan ng variable na may access token na idinagdag sa GitLab (β€œPaghahanda ng mga account”, p. 11). Natural, sa format $variableName
    5. -StorePasswordInClearText β€” isang hack para i-bypass ang error na tinanggihan ng access (Hindi ako ang unang nakatapak sa kalaykay na ito)
    6. Sa kaso ng mga error, maaaring maging kapaki-pakinabang na magdagdag -verbosity detailed
  3. Ipinapadala namin ang package sa pinagmulan: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
    1. Ipinapadala namin ang lahat ng mga pakete mula sa kasalukuyang direktoryo, kaya *.nupkg.
    2. name - mula sa hakbang sa itaas.
    3. key - anumang linya. Sa Azure DevOps, sa window ng Connect to feed, ang halimbawang linya ay palaging az.
    4. -skipduplicate β€” kung susubukan mong magpadala ng umiiral nang package nang wala ang key na ito, magbabalik ng error ang source 409 Conflict; gamit ang susi, ang pagpapadala ay lalaktawan.

Ngayon ay i-set up natin ang paglikha ng dokumentasyon:

  1. Upang magsimula sa, sa repositoryo, sa master branch, sinisimulan namin ang docfx project. Upang gawin ito, kailangan mong patakbuhin ang utos mula sa ugat docfx init at interactive na itakda ang mga pangunahing parameter para sa pag-assemble ng dokumentasyon. Detalyadong paglalarawan ng minimal na pag-setup ng proyekto dito.
    1. Kapag nagse-set up, mahalagang tukuyin ang direktoryo ng output ..public - Ang GitLab bilang default ay kinukuha ang mga nilalaman ng pampublikong folder sa ugat ng repositoryo bilang pinagmulan para sa Mga Pahina. kasi ang proyekto ay matatagpuan sa isang folder na naka-nested sa repository - magdagdag ng isang exit sa susunod na antas sa path.
  2. Itulak natin ang mga pagbabago sa GitLab.
  3. Magdagdag ng gawain sa configuration ng pipeline pages (nakareserbang salita para sa mga gawain sa pag-publish ng site sa Mga Pahina ng GitLab):
    1. Script:
      1. nuget install docfx.console -version 2.51.0 - i-install ang docfx; Ang bersyon ay ibinigay upang matiyak na ang mga landas sa pag-install ng package ay tama.
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - pagkolekta ng dokumentasyon
    2. Artifacts node:

pages:
  # snip
  artifacts:
    paths:
      - public

Lyrical digression tungkol sa docfx

Noong nakaraan, kapag nagse-set up ng isang proyekto, tinukoy ko ang source ng code para sa dokumentasyon bilang isang file ng solusyon. Ang pangunahing kawalan ay ang dokumentasyon ay nilikha din para sa mga proyekto ng pagsubok. Kung hindi ito kinakailangan, maaari mong itakda ang halagang ito sa node metadata.src:

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

  1. metadata.src.src: "../" β€” umakyat ng isang antas na may kaugnayan sa lokasyon docfx.json, dahil Ang paghahanap sa puno ng direktoryo ay hindi gumagana sa mga pattern.
  2. metadata.src.files: ["**/*.csproj"] β€” isang pandaigdigang pattern, kinokolekta namin ang lahat ng mga proyekto ng C# mula sa lahat ng mga direktoryo.
  3. metadata.src.exclude: ["*.tests*/**"] - pandaigdigang pattern, ibukod ang lahat mula sa mga folder na may .tests Sa pamagat

Subtotal

Ang simpleng pagsasaayos na ito ay maaaring malikha sa literal na kalahating oras at isang pares ng mga tasa ng kape, na magbibigay-daan sa iyo upang suriin sa bawat kahilingan sa pagsasama at ipadala ito sa master na ang code ay pinagsama-sama at ang mga pagsubok ay pumasa, nag-iipon ng isang bagong package, pag-update ng dokumentasyon at kasiya-siya sa mata na may magagandang badge sa proyektong README.

Pangwakas na .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

Nagsasalita ng mga badge

Ito ay para sa kanilang kapakanan na ang lahat ay nagsimula!

Ang mga badge na may mga pipeline status at saklaw ng code ay available sa GitLab sa mga setting ng CI/CD sa Gtntral pipelines block:

Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

Gumawa ako ng badge na may link sa dokumentasyon sa platform shields.io β€” lahat ay medyo diretso doon, maaari kang lumikha ng iyong sariling badge at matanggap ito gamit ang isang kahilingan.

![ΠŸΡ€ΠΈΠΌΠ΅Ρ€ с Shields.io](https://img.shields.io/badge/custom-badge-blue)

Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

Binibigyang-daan ka rin ng Azure DevOps Artifacts na gumawa ng mga badge para sa mga package na nagpapahiwatig ng pinakabagong bersyon. Upang gawin ito, sa pinagmulan sa website ng Azure DevOps, kailangan mong mag-click sa Lumikha ng badge para sa napiling pakete at kopyahin ang markdown markup:

Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

Isang gabay sa CI/CD sa GitLab para sa (halos) ganap na baguhan

Nagdaragdag ng kagandahan

Itinatampok namin ang mga karaniwang fragment ng configuration

Habang isinusulat ang configuration at naghahanap sa dokumentasyon, nakatagpo ako ng isang kawili-wiling feature ng YAML - muling paggamit ng mga fragment.

Tulad ng nakikita mo mula sa mga setting ng gawain, lahat sila ay nangangailangan ng isang tag windows sa runner, at na-trigger kapag nagpapadala ng kahilingan sa pagsasama sa master/paggawa ng kahilingan sa pagsasama (maliban sa dokumentasyon). Idagdag natin ito sa fragment na gagamitin nating muli:

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

At ngayon maaari nating ipasok ang naunang inihayag na fragment sa paglalarawan ng gawain:

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

Ang mga pangalan ng fragment ay dapat magsimula sa isang tuldok upang maiwasang mabigyang-kahulugan bilang isang gawain.

Pag-bersyon ng package

Kapag lumilikha ng isang pakete, sinusuri ng compiler ang mga switch ng command line, at sa kanilang kawalan, ang mga file ng proyekto; Ang pagkakaroon ng natagpuan ang node ng Bersyon, ito ay tumatagal ng halaga nito bilang ang bersyon ng package na binuo. Lumalabas na upang makabuo ng isang pakete na may bagong bersyon, kailangan mong i-update ito sa file ng proyekto o ipasa ito bilang argumento ng command line.

Magdagdag pa tayo ng isa pang hiling - hayaan ang pinakamababang dalawang numero sa bersyon ang taon at petsa ng pagbuo ng package, at magdagdag ng mga bersyon ng prerelease. Siyempre, maaari mong idagdag ang data na ito sa file ng proyekto at suriin ito bago ang bawat pagsusumite - ngunit maaari mo ring gawin ito sa pipeline, pagkolekta ng bersyon ng package mula sa konteksto at ipasa ito sa pamamagitan ng argumento ng command line.

Sumang-ayon tayo na kung ang mensahe ng commit ay naglalaman ng isang linya tulad ng release (v./ver./version) <version number> (rev./revision <revision>)?, pagkatapos ay kukunin namin ang bersyon ng pakete mula sa linyang ito, dagdagan ito ng kasalukuyang petsa at ipasa ito bilang isang argumento sa utos dotnet pack. Sa kawalan ng isang linya, hindi lang namin i-assemble ang package.

Ang sumusunod na script ay malulutas ang problemang ito: 

# рСгулярноС Π²Ρ‹Ρ€Π°ΠΆΠ΅Π½ΠΈΠ΅ для поиска строки с вСрсиСй
$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

Pagdaragdag ng script sa isang gawain pack and deploy job at mahigpit na obserbahan ang pagpupulong ng mga pakete kung mayroong ibinigay na linya sa commit message.

Sa kabuuan

Pagkatapos gumugol ng halos kalahating oras hanggang isang oras sa pagsulat ng configuration, pag-debug sa lokal na powershell at, posibleng, ilang hindi matagumpay na paglulunsad, nakatanggap kami ng simpleng configuration para sa pag-automate ng mga nakagawiang gawain.

Siyempre, ang GitLab CI/CD ay mas malawak at multifaceted kaysa sa maaaring makita pagkatapos basahin ang gabay na ito - hindi totoo yan. meron pa Auto DevOps oonagpapahintulot

awtomatikong makita, bumuo, subukan, i-deploy, at subaybayan ang iyong mga application

Ngayon ang mga plano ay mag-configure ng pipeline para sa pag-deploy ng mga application sa Azure, gamit ang Pulumi at awtomatikong pag-detect ng target na kapaligiran, na tatalakayin sa susunod na artikulo.

Pinagmulan: www.habr.com

Magdagdag ng komento