🥇Giya sa CI/CD sa GitLab para sa (halos) hingpit nga nagsugod

O kung giunsa pagkuha ang matahum nga mga badge alang sa imong proyekto sa usa ka gabii nga dali nga pag-coding

Tingali, ang matag developer nga adunay labing menos usa ka proyekto sa binuhi sa usa ka punto adunay usa ka itch bahin sa matahum nga mga badge nga adunay mga status, code coverage, mga bersyon sa pakete sa nuget ... Ug kini nga itch nagdala kanako sa pagsulat niini nga artikulo. Sa pagpangandam sa pagsulat niini, nakuha nako kini nga katahum sa usa sa akong mga proyekto:

Kini nga artikulo maggiya kanimo sa sukaranan nga pag-setup sa padayon nga paghiusa ug paghatud alang sa usa ka proyekto sa librarya sa .Net Core nga klase sa GitLab, pagmantala sa dokumentasyon sa GitLab Pages, ug pagduso sa mga gitukod nga pakete sa usa ka pribado nga feed sa Azure DevOps.

Ang VS Code gigamit isip development environment nga adunay extension GitLab Workflow (alang sa pag-validate sa settings file direkta gikan sa development environment).

Mubo nga pasiuna

CD - kini ba sa dihang imong giduso, ug ang tanan nahulog na sa kliyente?

Unsa ang CI / CD ug ngano nga kinahanglan nimo kini - dali nimo kini i-google. Pangitaa ang kompleto nga dokumentasyon sa pag-configure sa mga pipeline sa GitLab sayon usab. Dinhi ako sa makadiyot ug, kung mahimo, nga walay mga sayup naghulagway sa proseso sa sistema gikan sa panan-aw sa usa ka langgam:

ang developer nagpadala usa ka pasalig sa repository, nagmugna usa ka hangyo sa paghiusa pinaagi sa site, o sa laing paagi, sa dayag o dili klaro nga pagsugod sa pipeline,
ang tanan nga mga buluhaton gipili gikan sa pagsumpo, ang mga kondisyon nga nagtugot kanila nga ilunsad sa gihatag nga konteksto,
ang mga buluhaton giorganisar sumala sa ilang mga yugto,
ang mga yugto gipatuman sa baylo - i.e. managsama ang tanan nga mga buluhaton niini nga yugto nahuman,
kung ang entablado mapakyas (ie, labing menos usa sa mga buluhaton sa entablado mapakyas), ang pipeline mohunong (halos kanunay),
kung ang tanan nga mga yugto malampuson nga nahuman, ang pipeline giisip nga malampuson.

Busa, kita adunay:

pipeline - usa ka hugpong sa mga buluhaton nga giorganisar ngadto sa mga yugto diin mahimo nimong tukuron, sulayan, code sa pakete, i-deploy ang nahuman nga pagtukod sa usa ka serbisyo sa panganod, ug uban pa,
entablado (stage) - yunit sa organisasyon sa pipeline, adunay 1+ nga buluhaton,
buluhaton (trabaho) usa ka yunit sa trabaho sa pipeline. Naglangkob kini sa usa ka script (mandatory), mga kondisyon sa paglansad, mga setting alang sa pagmantala / pag-caching sa mga artifact, ug daghan pa.

Tungod niini, ang tahas sa pag-set up sa CI / CD moabut sa paghimo sa usa ka hugpong sa mga buluhaton nga nagpatuman sa tanan nga kinahanglan nga mga aksyon alang sa pagtukod, pagsulay ug pagmantala sa code ug mga artifact.

Sa wala pa magsugod: ngano?

Nganong Gitlab?

Tungod kay kung gikinahanglan ang paghimo og mga pribadong repository alang sa mga proyekto sa binuhi, gibayran sila sa GitHub, ug ako hakog. Ang mga repository nahimo nga libre, apan hangtod karon dili pa kini igo nga hinungdan nga mobalhin ako sa GitHub.

Ngano nga dili Azure DevOps Pipelines?

Tungod kay didto ang setting elementarya - ang kahibalo sa command line wala gani gikinahanglan. Ang panagsama sa mga eksternal nga git providers - sa usa ka magtiayon nga mga pag-klik, pag-import sa mga yawe sa SSH aron ipadala ang mga commit sa repository - usab, ang pipeline dali nga ma-configure bisan dili gikan sa usa ka template.

Pagsugod nga posisyon: kung unsa ang naa nimo ug kung unsa ang gusto nimo

Kami adunay:

repository sa GitLab.

Gusto namo:

awtomatik nga asembliya ug pagsulay alang sa matag hangyo sa paghiusa,
pagtukod og mga pakete alang sa matag hangyo sa paghiusa ug pagduso ngadto sa agalon, basta adunay usa ka linya sa commit nga mensahe,
pagpadala sa gitukod nga mga pakete sa usa ka pribado nga feed sa Azure DevOps,
asembliya sa dokumentasyon ug publikasyon sa GitLab Pages,
mga badge!11

Ang gihulagway nga mga kinahanglanon organikong nahulog sa mosunod nga modelo sa pipeline:

Yugto 1 - Asembliya
- Gikolekta namo ang code, gimantala ang mga output file isip mga artifact
Stage 2 - pagsulay
- Nakuha namon ang mga artifact gikan sa yugto sa pagtukod, pagpadagan sa mga pagsulay, pagkolekta sa datos sa pagsakup sa code
Stage 3 - Isumite
- Buluhaton 1 - paghimo sa nuget package ug ipadala kini sa Azure DevOps
- Buluhaton 2 - gikolekta namo ang site gikan sa xmldoc sa source code ug gimantala kini sa GitLab Pages

Magsugod kita!

Pagkolekta sa configuration

Pag-andam sa mga account

Paghimo og account sa Microsoft Azure
Adto sa Mga Azure DevOps
Naghimo kami usa ka bag-ong proyekto
1. Ngalan - bisan unsa
2. Visibility - bisan unsa
Kung imong i-klik ang Create button, ang proyekto pagahimoon ug ikaw ma-redirect sa iyang panid. Sa kini nga panid, mahimo nimong ma-disable ang wala kinahanglana nga mga bahin pinaagi sa pag-adto sa mga setting sa proyekto (ubos nga link sa lista sa wala -> Kinatibuk-ang Pagtan-aw -> Pag-block sa Azure DevOps Services)
Adto sa Atrifacts, i-klik Paghimo feed
1. Pagsulod sa ngalan sa tinubdan
2. Pilia ang visibility
3. Uncheck Ilakip ang mga pakete gikan sa komon nga publikong tinubdan, aron ang tinubdan dili mahimong dump nuget clone
I-klik ang Connect to feed, pilia ang Visual Studio, kopyaha ang Source gikan sa Machine Setup block
Adto sa mga setting sa account, pilia ang Personal Access Token
Paghimo og bag-ong access token
1. Ngalan - arbitraryo
2. Organisasyon - Karon
3. Balido alang sa labing taas nga 1 ka tuig
4. Kasangkaran - Pagputos/Pagbasa ug Pagsulat
Kopyaha ang gibuhat nga token - pagkahuman sa pagsira sa modal nga bintana, ang kantidad dili magamit
Lakaw ngadto sa mga setting sa repository sa GitLab, pilia ang mga setting sa CI / CD
Pagpalapad sa block sa Variable, pagdugang og bag-o
1. Ngalan - bisan unsa nga walay mga luna (magamit sa command shell)
2. Value - access token gikan sa parapo 9
3. Pilia ang Mask variable

Nakompleto niini ang pre-configuration.

Pag-andam sa configuration framework

Sa kasagaran, ang CI/CD configuration sa GitLab naggamit sa file .gitlab-ci.yml gikan sa gamut sa repositoryo. Mahimo nimong itakda ang usa ka arbitraryong agianan sa kini nga file sa mga setting sa repository, apan sa kini nga kaso dili kinahanglan.

Sama sa imong makita gikan sa extension, ang file adunay usa ka configuration sa format YAML. Ang mga detalye sa dokumentasyon kung unsang mga yawe ang mahimong masulod sa taas nga lebel sa pag-configure, ug sa matag usa sa mga salag nga lebel.

Una, magdugang ta og link sa docker image sa configuration file, diin ang mga buluhaton himoon. Alang niini atong makita .Net Core nga mga hulagway nga panid sa Docker Hub. ang GitHub adunay usa ka detalyado nga giya kung unsang imahe ang pilion alang sa lainlaing mga buluhaton. Ang usa ka imahen nga adunay .Net Core 3.1 ang angay alang kanamo nga magtukod, busa ayaw kabalaka nga idugang ang una nga linya sa pagsumpo

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

Karon, kung gilansad ang pipeline gikan sa repository sa imahe sa Microsoft, ma-download ang piho nga imahe, diin ang tanan nga mga buluhaton gikan sa pag-configure ipatuman.

Ang sunod nga lakang mao ang pagdugang stageni. Sa kasagaran, gihubit sa GitLab ang 5 nga mga yugto:

.pre - gihimo hangtod sa tanan nga mga yugto,
.post - gihimo pagkahuman sa tanan nga mga yugto,
build - una pagkahuman .pre entablado,
test - ikaduhang hugna,
deploy - ang ikatulo nga yugto.

Wala’y makapugong kanimo sa pagpahayag niini nga klaro, bisan pa. Ang han-ay diin ang mga lakang gilista makaapekto sa han-ay diin kini gihimo. Para sa pagkakompleto, idugang nato ang configuration:

stages:
  - build
  - test
  - deploy

Alang sa pag-debug, makatarunganon nga makakuha og kasayuran bahin sa palibot diin gipatuman ang mga buluhaton. Atong idugang ang usa ka global nga hugpong sa mga sugo nga ipatuman sa dili pa ang matag buluhaton before_script:

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

Nagpabilin kini nga pagdugang bisan usa ka buluhaton aron kung ipadala ang mga commit, magsugod ang pipeline. Sa pagkakaron, magdugang ta og walay sulod nga buluhaton aron ipakita:

dummy job:
  script:
    - echo ok

Nagsugod kami sa pag-validate, nakakuha kami usa ka mensahe nga maayo ang tanan, nagpasalig kami, nagduso kami, gitan-aw namon ang mga resulta sa site ... Ug nakakuha kami usa ka sayup sa script - bash: .PSVersion: command not found. wtf?

Ang tanan lohikal - sa default, ang mga runner (responsable sa pagpatuman sa mga script sa buluhaton ug gihatag sa GitLab) naggamit bash sa pagpatuman sa mga sugo. Mahimo nimo kini nga ayohon pinaagi sa dayag nga pagpiho sa paghulagway sa buluhaton kung unsa nga mga tag ang kinahanglan nga adunay tigpatuman nga pipeline runner:

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

Nindot! Ang pipeline karon nagdagan.

Ang usa ka matinagdanon nga magbabasa, nga gisubli ang gipakita nga mga lakang, makamatikod nga ang buluhaton nahuman sa entablado test, bisan tuod wala namo gitino ang entablado. Sama sa imong gihunahuna test mao ang default nga lakang.

Ipadayon nato ang paghimo sa skeleton sa configuration pinaagi sa pagdugang sa tanang buluhaton nga gihulagway sa ibabaw:

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

Nakakuha kami usa ka dili kaayo magamit, apan bisan pa sa husto nga pipeline.

Pag-set up sa mga trigger

Tungod sa kamatuoran nga walay trigger filters ang gipiho alang sa bisan unsa nga mga buluhaton, ang pipeline hingpit ipatuman sa matag higayon nga ang usa ka commit iduso ngadto sa repositoryo. Tungod kay dili kini ang gitinguha nga pamatasan sa kinatibuk-an, magbutang kami mga pagsala sa gatilyo alang sa mga buluhaton.

Ang mga filter mahimong ma-configure sa duha ka mga format: lamang/gawas и nga mga lagda. Sa mubo, only/except nagtugot kanimo sa pag-configure sa mga filter pinaagi sa mga trigger (merge_request, pananglitan - nagtakda sa buluhaton nga ipatuman sa matag higayon nga ang usa ka hangyo sa pagbitad gihimo ug sa matag higayon nga ang mga pasalig ipadala ngadto sa sanga nga maoy tinubdan sa hangyo sa paghiusa) ug mga ngalan sa sanga (lakip ang paggamit sa regular nga mga ekspresyon); rules nagtugot kanimo sa pagpahiangay sa usa ka hugpong sa mga kondisyon ug, opsyonal, usbon ang kondisyon sa pagpatuman sa buluhaton depende sa kalampusan sa nangaging mga buluhaton (when sa GitLab CI/CD).

Atong hinumdoman ang usa ka hugpong sa mga kinahanglanon - asembliya ug pagsulay lamang alang sa paghiusa sa hangyo, pagputos ug pagpadala sa Azure DevOps - alang sa paghiusa sa hangyo ug pagduso ngadto sa agalon, paghimo sa dokumentasyon - alang sa pagduso ngadto sa agalon.

Una, atong i-set up ang buluhaton sa paghimo sa code pinaagi sa pagdugang sa usa ka lagda nga nagdilaab lamang sa hangyo sa paghiusa:

build job:
  # snip
  only:
    - merge_request

Karon atong i-set up ang buluhaton sa pagputos aron masunog ang hangyo sa paghiusa ug idugang ang mga pasalig sa agalon:

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

Sama sa imong makita, ang tanan yano ug prangka.

Mahimo usab nimo nga itakda ang buluhaton sa pagpabuto lamang kung ang usa ka hangyo sa paghiusa gihimo uban ang usa ka piho nga target o gigikanan nga sanga:

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

Ubos sa mga kondisyon, mahimo nimong gamiton mga variable nga gilista dinhi; mga lagda rules dili uyon sa mga lagda only/except.

Pag-configure sa Pagtipig sa Artifact

Atol sa usa ka buluhaton build job magtukod kita og mga artifact nga magamit pag-usab sa sunod nga mga buluhaton. Aron mahimo kini, kinahanglan nimo nga idugang ang mga agianan sa pag-configure sa buluhaton, ang mga file diin kinahanglan nimo nga i-save ug gamiton pag-usab sa mosunod nga mga buluhaton, sa yawe. artifacts:

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

Gisuportahan sa mga agianan ang mga wildcard, nga siguradong nagpadali sa pagtakda niini.

Kung ang usa ka buluhaton nagmugna og mga artifact, nan ang matag sunod nga buluhaton makahimo sa pag-access niini - sila mahimutang sa parehas nga mga agianan nga may kalabotan sa repository nga gamut nga nakolekta gikan sa orihinal nga buluhaton. Ang mga artifact magamit usab aron ma-download sa site.

Karon nga kita adunay usa ka configuration framework andam (ug gisulayan), kita makapadayon sa aktuwal nga pagsulat scripts alang sa mga buluhaton.

Nagsulat kami og mga script

Tingali, sa usa ka panahon, sa usa ka galaxy nga layo, layo, ang mga proyekto sa pagtukod (lakip ang mga naa sa .net) gikan sa command line usa ka sakit. Karon mahimo nimong tukuron, sulayan ug imantala ang proyekto sa 3 nga mga koponan:

dotnet build
dotnet test
dotnet pack

Siyempre, adunay pipila ka mga nuances nga tungod niini atong makomplikado ang mga sugo.

Gusto namon ang usa ka pagpagawas sa pagtukod, dili usa ka debug nga pagtukod, mao nga among idugang ang matag sugo -c Release
Sa pagsulay, gusto namong mangolekta og datos sa coverage sa code, mao nga kinahanglan namong iapil ang coverage analyzer sa mga test library:
1. Idugang ang package sa tanang test library coverlet.msbuild: dotnet add package coverlet.msbuild gikan sa folder sa proyekto
2. Idugang sa test run nga sugo /p:CollectCoverage=true
3. Pagdugang usa ka yawe sa pag-configure sa buluhaton sa pagsulay aron makakuha mga resulta sa pagsakup (tan-awa sa ubos)
Kung giputos ang code sa mga pakete sa nuget, itakda ang direktoryo sa output alang sa mga pakete: -o .

Pagkolekta sa datos sa coverage sa code

Human sa pagpadagan sa mga pagsulay, ang Coverlet nag-imprenta sa mga estadistika 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% |
+---------+--------+--------+--------+

Gitugotan ka sa GitLab nga ipiho ang usa ka regular nga ekspresyon aron makakuha mga estadistika, nga mahimo’g makuha sa porma sa usa ka badge. Ang regular nga ekspresyon gipiho sa mga setting sa buluhaton nga adunay yawe coverage; ang ekspresyon kinahanglan adunay usa ka grupo sa pagkuha, ang kantidad niini ipasa sa badge:

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

Dinhi atong makuha ang mga estadistika gikan sa usa ka linya nga adunay kinatibuk-ang coverage sa linya.

Imantala ang mga pakete ug dokumentasyon

Ang duha nga mga aksyon gikatakda alang sa katapusan nga yugto sa pipeline - tungod kay ang asembliya ug mga pagsulay milabay na, mahimo namong ipaambit ang among mga kalamboan sa kalibutan.

Una, ikonsiderar ang pagmantala sa tinubdan sa package:

Kung ang proyekto walay nuget configuration file (nuget.config), paghimo og bag-o: dotnet new nugetconfig

Para unsa: ang hulagway mahimong walay access sa pagsulat sa global (user ug machine) configurations. Aron dili madakpan ang mga kasaypanan, maghimo lang kami og bag-ong lokal nga configuration ug magtrabaho uban niini.
Magdugang ta og bag-ong tinubdan sa package sa lokal nga configuration: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name - lokal nga ngalan sa tinubdan, dili kritikal
2. url - URL sa tinubdan gikan sa yugto nga "Pag-andam sa mga asoy", p. 6
3. organization - ngalan sa organisasyon sa Azure DevOps
4. gitlab variable - ang ngalan sa variable nga adunay access token nga gidugang sa GitLab ("Pag-andam sa mga account", p. 11). Natural, sa porma $variableName
5. -StorePasswordInClearText - usa ka hack aron malaktawan ang sayup nga gipanghimakak sa pag-access (Dili ako ang una nga nakatunob niining rake)
6. Sa kaso sa mga sayop, kini mahimong mapuslanon sa pagdugang -verbosity detailed
Pagpadala sa package ngadto sa tinubdan: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Gipadala namo ang tanang mga pakete gikan sa kasamtangan nga direktoryo, busa *.nupkg.
2. name - gikan sa lakang sa ibabaw.
3. key - bisan unsang linya. Sa Azure DevOps, sa Connect to feed window, ang panig-ingnan mao ang kanunay nga linya az.
4. -skipduplicate - kung mosulay sa pagpadala sa naa na nga pakete nga wala kini nga yawe, ang gigikanan magbalik usa ka sayup 409 Conflict; uban sa yawe, ang pagpadala malaktawan.

Karon atong i-set up ang paghimo sa dokumentasyon:

Una, sa repository, sa master branch, among gisugdan ang docfx project. Aron mahimo kini, pagdagan ang mando gikan sa gamut docfx init ug interactive nga itakda ang yawe nga mga parameter para sa dokumentasyon sa pagtukod. Detalyadong paghulagway sa minimum nga pag-setup sa proyekto dinhi.
1. Kung nag-configure, hinungdanon nga ipiho ang direktoryo sa output ..public - GitLab sa default nagkuha sa mga sulud sa publiko nga folder sa gamut sa repository ingon usa ka gigikanan sa Mga Panid. Kay ang proyekto mahimutang sa usa ka folder nga nagsalag sa repository - pagdugang usa ka output sa lebel sa agianan.
Atong iduso ang mga pagbag-o sa GitLab.
Pagdugang og buluhaton sa configuration sa pipeline pages (gireserba nga pulong alang sa mga buluhaton sa pagmantala sa site sa GitLab Pages):
1. Script:
  1. nuget install docfx.console -version 2.51.0 - i-install ang docfx; ang bersyon gipiho aron masiguro nga husto ang mga agianan sa pag-install sa package.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - pagkolekta sa dokumentasyon
2. Mga artifact sa node:

pages:
  # snip
  artifacts:
    paths:
      - public

Lyrical digression bahin sa docfx

Kaniadto, sa pag-set up sa usa ka proyekto, akong gipiho ang gigikanan sa code alang sa dokumentasyon ingon usa ka file sa solusyon. Ang nag-unang disbentaha mao nga ang dokumentasyon gihimo usab alang sa mga proyekto sa pagsulay. Kung dili kini kinahanglan, mahimo nimong ibutang kini nga kantidad sa node metadata.src:

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

metadata.src.src: "../" - kita moadto sa usa ka lebel pataas nga may kalabotan sa lokasyon docfx.json, kay sa mga pattern, ang pagpangita sa punoan sa direktoryo dili molihok.
metadata.src.files: ["**/*.csproj"] - usa ka global nga sumbanan, among gikolekta ang tanan nga mga proyekto sa C # gikan sa tanan nga mga direktoryo.
metadata.src.exclude: ["*.tests*/**"] - global nga sumbanan, dili iapil ang tanan gikan sa mga folder nga adunay .tests Sa ulohan

Subtotal

Ang ingon nga usa ka yano nga pag-configure mahimong mabuhat sa tunga sa oras ug usa ka pares nga mga tasa sa kape, nga magtugot kanimo sa pagsusi nga ang code gitukod ug ang mga pagsulay moagi, paghimo usa ka bag-ong pakete, pag-update sa dokumentasyon ug pagpahimuot sa mata nga adunay matahum. mga badge sa README sa proyekto sa matag hangyo sa paghiusa ug ipadala sa agalon.

Katapusan nga .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

Naghisgot bahin sa mga badge

Tungod nila, human sa tanan, ang tanan nagsugod!

Ang mga badge nga adunay mga pipeline status ug code coverage anaa sa GitLab sa CI/CD settings sa Gtntral pipelines block:

Naghimo ko og badge nga adunay link sa dokumentasyon sa plataporma taming.io - ang tanan prangka didto, mahimo ka maghimo sa imong kaugalingon nga badge ug madawat kini gamit ang usa ka hangyo.

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

Gitugotan ka usab sa Azure DevOps Artifacts nga maghimo mga badge alang sa mga pakete nga adunay labing bag-ong bersyon. Aron mahimo kini, sa gigikanan sa site sa Azure DevOps, kinahanglan nimo nga i-klik ang Paghimo badge alang sa napili nga pakete ug kopyaha ang markdown markup:

Pagdugang katahom

Pag-highlight sa Komon nga Configuration Fragment

Samtang nagsulat sa pag-configure ug pagpangita pinaagi sa dokumentasyon, nakit-an nako ang usa ka makapaikag nga bahin sa YAML - gigamit pag-usab ang mga tipik.

Sama sa imong makita gikan sa mga setting sa buluhaton, silang tanan nanginahanglan sa tag windows sa runner, ug ma-trigger kung ang usa ka hangyo sa paghiusa ipadala sa agalon/gibuhat (gawas sa dokumentasyon). Atong idugang kini sa tipik nga atong gamiton pag-usab:

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

Ug karon mahimo natong isulod ang tipik nga gipahayag sa sayo pa sa paghulagway sa buluhaton:

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

Ang mga ngalan sa tipik kinahanglan magsugod sa usa ka tulbok, aron dili mahubad nga usa ka buluhaton.

Pag-bersyon sa pakete

Sa paghimo sa usa ka pakete, ang compiler nagsusi sa command line switch, ug sa ilang pagkawala, ang mga file sa proyekto; kung makit-an ang usa ka node nga Bersyon, gikuha ang kantidad niini ingon nga bersyon sa package nga gitukod. Kini nahimo nga aron makahimo usa ka pakete nga adunay bag-ong bersyon, kinahanglan nimo nga i-update kini sa file sa proyekto o ipasa kini ingon usa ka argumento sa linya sa command.

Atong idugang ang usa pa ka Wishlist - himoa nga ang menor de edad nga duha ka numero sa bersyon mao ang tuig ug petsa sa pagtukod sa package, ug idugang ang prerelease nga mga bersyon. Siyempre, mahimo nimong idugang kini nga datos sa file sa proyekto ug susihon sa wala pa ang matag pagsumite - apan mahimo usab nimo kini sa pipeline, pagkolekta sa bersyon sa pakete gikan sa konteksto ug ipasa kini sa argumento sa command line.

Magkasabot ta nga kung ang commit nga mensahe adunay usa ka linya sama sa release (v./ver./version) <version number> (rev./revision <revision>)?, unya atong kuhaon ang bersyon sa pakete gikan niini nga linya, dugangan kini sa kasamtangan nga petsa ug ipasa kini isip argumento sa sugo dotnet pack. Kung wala’y linya, dili gyud namo kolektahon ang pakete.

Ang mosunod nga script makasulbad niini nga problema:

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

Pagdugang og script sa usa ka buluhaton pack and deploy job ug pag-obserbar sa asembliya sa mga pakete nga higpit sa presensya sa usa ka gihatag nga string sa commit nga mensahe.

Total

Human sa paggugol ug mga tunga sa oras o usa ka oras sa pagsulat sa configuration, pag-debug sa lokal nga powershell ug, posible, sa usa ka magtiayon nga wala molampos nga paglansad, nakakuha kami usa ka yano nga pag-configure alang sa pag-automate sa naandan nga mga buluhaton.

Siyempre, ang GitLab CI / CD mas kaylap ug multifaceted kay sa makita human mabasa kini nga giya - dili kana tinuod. Didto gani Ang Auto DevOps maopagtugot

awtomatik nga makit-an, magtukod, magsulay, mag-deploy, ug magmonitor sa imong mga aplikasyon

Karon ang mga plano mao ang pag-configure sa usa ka pipeline alang sa pag-deploy sa mga aplikasyon sa Azure, gamit ang Pulumi ug awtomatik nga pagtino sa target nga palibot, nga hisgutan sa sunod nga artikulo.

Source: www.habr.com

Usa ka giya sa CI/CD sa GitLab alang sa (halos) hingpit nga nagsugod