ProHoster > blog > Gweinyddiaeth > Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

Neu sut i gael bathodynnau hardd ar gyfer eich prosiect mewn un noson o godio hawdd

Yn ôl pob tebyg, mae gan bob datblygwr sydd ag o leiaf un prosiect anifail anwes ar ryw adeg cosi am fathodynnau hardd gyda statws, sylw cod, fersiynau pecyn yn nuget ... Ac arweiniodd y cosi hwn fi i ysgrifennu'r erthygl hon. Wrth baratoi ar gyfer ei ysgrifennu, cefais y harddwch hwn yn un o fy mhrosiectau:

Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

Bydd yr erthygl hon yn eich arwain trwy'r gosodiad sylfaenol o integreiddio a chyflwyno parhaus ar gyfer prosiect llyfrgell dosbarth craidd .Net yn GitLab, cyhoeddi dogfennaeth i GitLab Pages, a gwthio pecynnau adeiledig i borthiant preifat yn Azure DevOps.

Defnyddiwyd VS Code fel yr amgylchedd datblygu gyda'r estyniad Llif Gwaith GitLab (ar gyfer dilysu'r ffeil gosodiadau yn uniongyrchol o'r amgylchedd datblygu).

Cyflwyniad Byr

CD - ai pan fyddwch chi'n gwthio, ac mae popeth eisoes wedi disgyn ar y cleient?

Beth yw CI / CD a pham mae ei angen arnoch chi - gallwch chi ei google yn hawdd. Dewch o hyd i ddogfennaeth gyflawn ar ffurfweddu piblinellau yn GitLab hefyd hawddgar. Yma byddaf yn disgrifio'n fyr ac, os yn bosibl, heb ddiffygion, broses y system o olwg aderyn:

  • mae'r datblygwr yn anfon ymrwymiad i'r gadwrfa, yn creu cais uno trwy'r wefan, neu mewn rhyw ffordd arall, yn benodol neu'n ymhlyg yn cychwyn y biblinell,
  • dewisir pob tasg o'r ffurfweddiad, y mae ei amodau yn caniatáu iddynt gael eu lansio yn y cyd-destun penodol,
  • trefnir tasgau yn ôl eu cyfnodau,
  • mae camau'n cael eu gweithredu yn eu tro - h.y. cyfochrog bod holl dasgau'r cam hwn wedi'u cwblhau,
  • os bydd y llwyfan yn methu (h.y., mae o leiaf un o dasgau’r llwyfan yn methu), mae’r biblinell yn stopio (bron bob amser),
  • os cwblheir pob cam yn llwyddiannus, ystyrir bod y biblinell yn llwyddiannus.

Felly, mae gennym ni:

  • piblinell - set o dasgau wedi'u trefnu'n gamau lle gallwch chi adeiladu, profi, pecynnu cod, gosod adeilad gorffenedig i wasanaeth cwmwl, ac ati,
  • llwyfan (cam) — uned trefnu piblinellau, yn cynnwys 1+ tasg,
  • tasg (swydd) yn uned o waith ar y gweill. Mae'n cynnwys sgript (gorfodol), amodau lansio, gosodiadau ar gyfer cyhoeddi / storio arteffactau, a llawer mwy.

Yn unol â hynny, mae'r dasg wrth sefydlu CI / CD yn dibynnu ar greu set o dasgau sy'n gweithredu'r holl gamau angenrheidiol ar gyfer adeiladu, profi a chyhoeddi cod ac arteffactau.

Cyn dechrau: pam?

  • Pam Gitlab?

Oherwydd pan ddaeth yn angenrheidiol i greu ystorfeydd preifat ar gyfer prosiectau anifeiliaid anwes, cawsant eu talu ar GitHub, ac roeddwn yn farus. Mae'r ystorfeydd wedi dod yn rhad ac am ddim, ond hyd yn hyn nid yw hyn yn ddigon o reswm i mi symud i GitHub.

  • Beth am Piblinellau Azure DevOps?

Oherwydd bod y gosodiad yn elfennol yno - nid oes angen gwybodaeth o'r llinell orchymyn hyd yn oed. Integreiddio â darparwyr git allanol - mewn cwpl o gliciau, mae mewnforio allweddi SSH i'w hanfon yn ymrwymo i'r ystorfa - hefyd, mae'r biblinell yn hawdd ei ffurfweddu hyd yn oed nid o dempled.

Safle cychwyn: beth sydd gennych chi a beth rydych chi ei eisiau

Mae gennym ni:

  • storfa yn GitLab.

Rydyn ni eisiau:

  • cydosod a phrofi awtomatig ar gyfer pob cais uno,
  • adeiladu pecynnau ar gyfer pob cais uno a gwthio i'r meistr, ar yr amod bod llinell benodol yn y neges ymrwymo,
  • anfon pecynnau adeiledig i borthiant preifat yn Azure DevOps,
  • cydosod dogfennaeth a chyhoeddi yn Tudalennau GitLab,
  • bathodynnau!11

Mae'r gofynion a ddisgrifir yn perthyn yn organig i'r model piblinellau canlynol:

  • Cam 1 - cynulliad
    • Rydym yn casglu'r cod, yn cyhoeddi'r ffeiliau allbwn fel arteffactau
  • Cam 2 - profi
    • Rydyn ni'n cael arteffactau o'r cam adeiladu, yn cynnal profion, yn casglu data cwmpas cod
  • Cam 3 - Cyflwyno
    • Tasg 1 - adeiladu'r pecyn nuget a'i anfon at Azure DevOps
    • Tasg 2 - rydym yn casglu'r safle o xmldoc yn y cod ffynhonnell ac yn ei gyhoeddi yn Tudalennau GitLab

Dewch inni ddechrau!

Casglu'r cyfluniad

Paratoi cyfrifon

  1. Creu cyfrif yn Microsoft asur

  2. Mynd i Azure DevOps

  3. Rydym yn creu prosiect newydd

    1. Enw - unrhyw
    2. Gwelededd - unrhyw
      Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

  4. Pan fyddwch yn clicio ar y botwm Creu, bydd y prosiect yn cael ei greu a byddwch yn cael eich ailgyfeirio i'w dudalen. Ar y dudalen hon, gallwch analluogi nodweddion diangen trwy fynd i osodiadau'r prosiect (dolen is yn y rhestr ar y chwith -> Trosolwg -> bloc Gwasanaethau Azure DevOps)
    Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

  5. Ewch i Atrifacts, cliciwch Creu porthiant

    1. Rhowch enw'r ffynhonnell
    2. Dewiswch welededd
    3. Dad-diciwch Cynnwys pecynnau o ffynonellau cyhoeddus cyffredin, fel nad yw'r ffynhonnell yn troi'n glôn dump nuget
      Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

  6. Cliciwch Connect i fwydo, dewiswch Visual Studio, copïwch Ffynhonnell o'r bloc Gosod Peiriant
    Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

  7. Ewch i osodiadau cyfrif, dewiswch Tocyn Mynediad Personol
    Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

  8. Creu tocyn mynediad newydd

    1. Enw - mympwyol
    2. Sefydliad - presennol
    3. Yn ddilys am uchafswm o 1 flwyddyn
    4. Cwmpas - Pecynnu/Darllen ac Ysgrifennu
      Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

  9. Copïwch y tocyn a grëwyd - ar ôl i'r ffenestr foddol gau, ni fydd y gwerth ar gael

  10. Ewch i'r gosodiadau ystorfa yn GitLab, dewiswch y gosodiadau CI / CD
    Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

  11. Ehangwch y bloc Newidynnau, ychwanegwch un newydd

    1. Enw - unrhyw un heb fylchau (bydd ar gael yn y plisgyn gorchymyn)
    2. Gwerth - tocyn mynediad o baragraff 9
    3. Dewiswch newidyn Mwgwd
      Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

Mae hyn yn cwblhau'r rhag-gyfluniad.

Paratoi'r fframwaith ffurfweddu

Yn ddiofyn, mae cyfluniad CI/CD yn GitLab yn defnyddio'r ffeil .gitlab-ci.yml o wraidd yr ystorfa. Gallwch osod llwybr mympwyol i'r ffeil hon yng ngosodiadau'r ystorfa, ond yn yr achos hwn nid yw'n angenrheidiol.

Fel y gwelwch o'r estyniad, mae'r ffeil yn cynnwys ffurfweddiad yn y fformat YAML. Mae'r ddogfennaeth yn nodi pa allweddi y gellir eu cynnwys ar lefel uchaf y ffurfweddiad, ac ar bob un o'r lefelau nythu.

Yn gyntaf, gadewch i ni ychwanegu dolen at ddelwedd y docwr yn y ffeil ffurfweddu, lle bydd y tasgau'n cael eu perfformio. Am hyn cawn Tudalen delweddau craidd .net ar Docker Hub. Yn GitHub mae canllaw manwl ar ba ddelwedd i'w dewis ar gyfer gwahanol dasgau. Mae delwedd gyda .Net Core 3.1 yn addas i ni ei adeiladu, felly mae croeso i chi ychwanegu'r llinell gyntaf i'r ffurfweddiad

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

Nawr, pan fydd y biblinell yn cael ei lansio o ystorfa ddelwedd Microsoft, bydd y ddelwedd benodedig yn cael ei lawrlwytho, lle bydd yr holl dasgau o'r cyfluniad yn cael eu gweithredu.

Y cam nesaf yw ychwanegu cam's. Yn ddiofyn, mae GitLab yn diffinio 5 cam:

  • .pre - perfformio hyd at bob cam,
  • .post - perfformio ar ôl pob cam,
  • build - cyntaf ar ôl .pre llwyfan,
  • test - ail gam,
  • deploy - y trydydd cam.

Nid oes dim yn eich atal rhag eu datgan yn benodol, fodd bynnag. Mae'r drefn y rhestrir y camau yn effeithio ar y drefn y cânt eu perfformio. I fod yn gyflawn, gadewch i ni ychwanegu at y ffurfweddiad:

stages:
  - build
  - test
  - deploy

Ar gyfer dadfygio, mae'n gwneud synnwyr i gael gwybodaeth am yr amgylchedd y cyflawnir y tasgau ynddo. Gadewch i ni ychwanegu set fyd-eang o orchmynion a fydd yn cael eu gweithredu cyn pob tasg before_script:

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

Mae angen ychwanegu o leiaf un dasg o hyd fel y bydd y biblinell yn dechrau pan fydd yr ymrwymiadau'n cael eu hanfon. Am y tro, gadewch i ni ychwanegu tasg wag i ddangos:

dummy job:
  script:
    - echo ok

Rydyn ni'n dechrau dilysu, rydyn ni'n cael neges bod popeth yn iawn, rydyn ni'n ymrwymo, rydyn ni'n gwthio, rydyn ni'n edrych ar y canlyniadau ar y wefan ... Ac rydyn ni'n cael gwall sgript - bash: .PSVersion: command not found. wtf?

Mae popeth yn rhesymegol - yn ddiofyn, mae rhedwyr (sy'n gyfrifol am weithredu sgriptiau tasg ac a ddarperir gan GitLab) yn defnyddio bash i weithredu gorchmynion. Gallwch drwsio hyn trwy nodi'n benodol yn nisgrifiad y dasg pa dagiau y dylai rhedwr y biblinell weithredu eu cael:

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

Gwych! Mae'r biblinell bellach yn rhedeg.

Bydd darllenydd astud, wedi ailadrodd y camau a nodir, yn sylwi bod y dasg wedi'i chwblhau yn y llwyfan test, er na wnaethom nodi'r cam. Fel y gallech ddyfalu test yw'r cam diofyn.

Gadewch i ni barhau i greu'r sgerbwd cyfluniad trwy ychwanegu'r holl dasgau a ddisgrifir uchod:

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

Cawsom biblinell nad oedd yn arbennig o ymarferol, ond serch hynny yn gywir.

Sefydlu sbardunau

Oherwydd y ffaith nad oes unrhyw hidlyddion sbardun wedi'u pennu ar gyfer unrhyw un o'r tasgau, bydd y biblinell yn llawn cael ei weithredu bob tro y mae ymrwymiad yn cael ei wthio i'r gadwrfa. Gan nad dyma'r ymddygiad dymunol yn gyffredinol, byddwn yn sefydlu hidlwyr sbardun ar gyfer tasgau.

Gellir ffurfweddu hidlwyr mewn dau fformat: yn unig/ac eithrio и rheolau. Yn fyr, only/except yn eich galluogi i ffurfweddu hidlwyr yn ôl sbardunau (merge_request, er enghraifft - yn gosod y dasg i'w chyflawni bob tro y bydd cais tynnu'n cael ei greu a phob tro yr ymrwymir yn cael ei anfon i'r gangen sy'n ffynhonnell yn y cais uno) ac enwau canghennau (gan gynnwys defnyddio ymadroddion rheolaidd); rules yn caniatáu ichi addasu set o amodau ac, yn ddewisol, newid yr amod cyflawni tasg yn dibynnu ar lwyddiant tasgau blaenorol (when yn GitLab CI/CD).

Gadewch i ni gofio set o ofynion - cydosod a phrofi yn unig ar gyfer cais uno, pecynnu ac anfon at Azure DevOps - ar gyfer cais uno a gwthio i'r meistr, cynhyrchu dogfennaeth - ar gyfer gwthio i'r meistr.

Yn gyntaf, gadewch i ni sefydlu'r dasg adeiladu cod trwy ychwanegu rheol sy'n tanio ar gais uno yn unig:

build job:
  # snip
  only:
    - merge_request

Nawr, gadewch i ni sefydlu'r dasg pecynnu i danio ar y cais uno ac ychwanegu ymrwymiadau i'r meistr:

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

Fel y gwelwch, mae popeth yn syml ac yn syml.

Gallwch hefyd osod y dasg i danio dim ond os bydd cais uno yn cael ei greu gyda tharged penodol neu gangen ffynhonnell:

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

O dan amodau, gallwch chi ddefnyddio newidynnau a restrir yma; rheolau rules anghydnaws â'r rheolau only/except.

Ffurfweddu Arbed Arteffact

Yn ystod tasg build job bydd gennym arteffactau adeiladu y gellir eu hailddefnyddio mewn tasgau dilynol. I wneud hyn, mae angen i chi ychwanegu'r llwybrau at ffurfweddiad y dasg, y ffeiliau y bydd angen i chi eu cadw a'u hailddefnyddio yn y tasgau canlynol, i'r allwedd artifacts:

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

Mae llwybrau'n cynnal cardiau gwyllt, sy'n bendant yn eu gwneud yn haws i'w gosod.

Os yw tasg yn creu arteffactau, yna bydd pob tasg ddilynol yn gallu cael mynediad iddynt - byddant yn cael eu lleoli ar hyd yr un llwybrau mewn perthynas â gwraidd y storfa a gasglwyd o'r dasg wreiddiol. Mae arteffactau hefyd ar gael i'w lawrlwytho o'r wefan.

Nawr bod gennym y fframwaith cyfluniad yn barod (a'i brofi), gallwn symud ymlaen i ysgrifennu sgriptiau ar gyfer tasgau.

Rydym yn ysgrifennu sgriptiau

Efallai, unwaith ar y tro, mewn galaeth ymhell, bell i ffwrdd, roedd adeiladu prosiectau (gan gynnwys y rhai ar .net) o'r llinell orchymyn yn boen. Nawr gallwch chi adeiladu, profi a chyhoeddi'r prosiect mewn 3 thîm:

dotnet build
dotnet test
dotnet pack

Yn naturiol, mae yna rai arlliwiau y byddwn yn cymhlethu rhywfaint ar y gorchmynion oherwydd hynny.

  1. Rydyn ni eisiau adeiladu rhyddhau, nid adeiladu dadfygio, felly rydyn ni'n ychwanegu at bob gorchymyn -c Release
  2. Wrth brofi, rydym am gasglu data cwmpas cod, felly mae angen i ni gynnwys dadansoddwr darpariaeth yn y llyfrgelloedd prawf:
    1. Ychwanegwch y pecyn i bob llyfrgell prawf coverlet.msbuild: dotnet add package coverlet.msbuild o ffolder prosiect
    2. Ychwanegu at y gorchymyn rhedeg prawf /p:CollectCoverage=true
    3. Ychwanegu allwedd i ffurfweddiad tasg y prawf i gael canlyniadau sylw (gweler isod)
  3. Wrth bacio'r cod i becynnau nuget, gosodwch y cyfeiriadur allbwn ar gyfer y pecynnau: -o .

Casglu data cwmpas cod

Ar ôl rhedeg y profion, mae printiau Coverlet yn rhedeg ystadegau i'r consol:

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% |
+---------+--------+--------+--------+

Mae GitLab yn caniatáu ichi nodi mynegiant rheolaidd i gael ystadegau, y gellir eu cael wedyn ar ffurf bathodyn. Mae'r mynegiant rheolaidd wedi'i nodi yn y gosodiadau tasg gyda'r allwedd coverage; rhaid i'r mynegiant gynnwys grŵp dal, a bydd ei werth yn cael ei drosglwyddo i'r bathodyn:

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

Yma rydym yn cael ystadegau o linell gyda chyfanswm cwmpas y llinell.

Cyhoeddi pecynnau a dogfennaeth

Mae'r ddau weithred wedi'u hamserlennu ar gyfer cam olaf y biblinell - ers i'r cynulliad a'r profion fynd heibio, gallwn rannu ein datblygiadau gyda'r byd.

Yn gyntaf, ystyriwch gyhoeddi i ffynhonnell y pecyn:

  1. Os nad oes gan y prosiect ffeil ffurfweddu nuget (nuget.config), creu un newydd: dotnet new nugetconfig

    Am beth: efallai na fydd gan y ddelwedd fynediad ysgrifenedig i gyfluniadau byd-eang (defnyddiwr a pheiriant). Er mwyn peidio â dal gwallau, rydym yn syml yn creu cyfluniad lleol newydd ac yn gweithio gydag ef.

  2. Gadewch i ni ychwanegu ffynhonnell pecyn newydd i'r cyfluniad lleol: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
    1. name - enw ffynhonnell leol, ddim yn hollbwysig
    2. url - URL y ffynhonnell o'r cam "Paratoi cyfrifon", t. 6
    3. organization - enw'r sefydliad yn Azure DevOps
    4. gitlab variable - enw'r newidyn gyda'r tocyn mynediad wedi'i ychwanegu at GitLab ("Paratoi cyfrifon", t. 11). Yn naturiol, yn y fformat $variableName
    5. -StorePasswordInClearText - darnia i osgoi'r gwall gwrthod mynediad (Nid fi yw'r cyntaf i gamu ar y rhaca hwn)
    6. Yn achos gwallau, gall fod yn ddefnyddiol ychwanegu -verbosity detailed
  3. Anfon y pecyn i'r ffynhonnell: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
    1. Rydym yn anfon pob pecyn o'r cyfeiriadur cyfredol, felly *.nupkg.
    2. name — o'r cam uchod.
    3. key - unrhyw linell. Yn Azure DevOps, yn y ffenestr Connect to feed, yr enghraifft yw'r llinell bob amser az.
    4. -skipduplicate - wrth geisio anfon pecyn sydd eisoes yn bodoli heb yr allwedd hon, bydd y ffynhonnell yn dychwelyd gwall 409 Conflict; gyda'r allwedd, bydd anfon yn cael ei hepgor.

Nawr, gadewch i ni sefydlu creu dogfennaeth:

  1. Yn gyntaf, yn yr ystorfa, yn y brif gangen, rydym yn cychwyn y prosiect docfx. I wneud hyn, rhedeg y gorchymyn o'r gwraidd docfx init a gosod y paramedrau allweddol ar gyfer dogfennaeth adeiladu yn rhyngweithiol. Disgrifiad manwl o'r gosodiad prosiect lleiaf yma.
    1. Wrth ffurfweddu, mae'n bwysig nodi'r cyfeiriadur allbwn ..public - Mae GitLab yn ddiofyn yn cymryd cynnwys y ffolder cyhoeddus yng ngwraidd yr ystorfa fel ffynhonnell Tudalennau. Achos bydd y prosiect yn cael ei leoli mewn ffolder wedi'i nythu yn y gadwrfa - ychwanegu allbwn i'r lefel i fyny yn y llwybr.
  2. Gadewch i ni wthio'r newidiadau i GitLab.
  3. Ychwanegu tasg at ffurfweddiad y biblinell pages (gair neilltuedig ar gyfer tasgau cyhoeddi gwefan yn GitLab Pages):
    1. Sgript:
      1. nuget install docfx.console -version 2.51.0 - gosod docfx; mae'r fersiwn wedi'i nodi i sicrhau bod y llwybrau gosod pecyn yn gywir.
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - casglu dogfennaeth
    2. Arteffactau nod:

pages:
  # snip
  artifacts:
    paths:
      - public

Digression telynegol am docfx

Yn flaenorol, wrth sefydlu prosiect, nodais ffynhonnell y cod ar gyfer y ddogfennaeth fel ffeil datrysiad. Y brif anfantais yw bod dogfennaeth hefyd yn cael ei chreu ar gyfer prosiectau prawf. Rhag ofn nad yw hyn yn angenrheidiol, gallwch chi osod y gwerth hwn i'r nod metadata.src:

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

  1. metadata.src.src: "../" - rydym yn mynd un lefel i fyny mewn perthynas â'r lleoliad docfx.json, achos mewn patrymau, nid yw chwilio'r goeden cyfeiriadur yn gweithio.
  2. metadata.src.files: ["**/*.csproj"] - patrwm byd-eang, rydym yn casglu holl brosiectau C # o bob cyfeiriadur.
  3. metadata.src.exclude: ["*.tests*/**"] - patrwm byd-eang, eithrio popeth o ffolderi gyda .tests Yn y teitl

Is-gyfanswm

Gellir creu cyfluniad mor syml mewn dim ond hanner awr a chwpl o gwpanau o goffi, a fydd yn caniatáu ichi wirio bod y cod wedi'i adeiladu a bod y profion yn mynd heibio, adeiladu pecyn newydd, diweddaru'r ddogfennaeth a phlesio'r llygad â hardd. bathodynnau yn y README y prosiect gyda phob cais uno ac anfon at y meistr.

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

Wrth siarad am fathodynnau

O’u herwydd, wedi’r cyfan, dechreuwyd popeth!

Mae bathodynnau gyda statws piblinellau a chwmpas cod ar gael yn GitLab yn y gosodiadau CI/CD ym mloc piblinellau Gtntral:

Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

Creais fathodyn gyda dolen i'r ddogfennaeth ar y platfform tarianau.io - mae popeth yn eithaf syml yno, gallwch greu eich bathodyn eich hun a'i dderbyn gan ddefnyddio cais.

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

Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

Mae Azure DevOps Artifacts hefyd yn caniatáu ichi greu bathodynnau ar gyfer pecynnau gyda'r fersiwn ddiweddaraf. I wneud hyn, yn y ffynhonnell ar wefan Azure DevOps, mae angen i chi glicio ar Creu bathodyn ar gyfer y pecyn a ddewiswyd a chopïo'r marcio i lawr:

Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

Canllaw i CI/CD yn GitLab ar gyfer y dechreuwr absoliwt (bron).

Ychwanegu harddwch

Amlygu Darnau Cyfluniad Cyffredin

Wrth ysgrifennu'r ffurfweddiad a chwilio trwy'r ddogfennaeth, deuthum ar draws nodwedd ddiddorol o YAML - ailddefnyddio darnau.

Fel y gallwch weld o'r gosodiadau tasg, mae angen y tag arnynt i gyd windows yn y rhedwr, ac yn cael eu sbarduno pan fydd cais uno yn cael ei anfon at y meistr/creu (ac eithrio dogfennaeth). Gadewch i ni ychwanegu hyn at y darn y byddwn yn ei ailddefnyddio:

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

A nawr gallwn fewnosod y darn a ddatganwyd yn gynharach yn y disgrifiad o'r dasg:

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

Rhaid i enwau darnau ddechrau gyda dot, er mwyn peidio â chael eu dehongli fel tasg.

Fersiwn pecyn

Wrth greu pecyn, mae'r casglwr yn gwirio'r switshis llinell orchymyn, ac yn eu habsenoldeb, y ffeiliau prosiect; pan fydd yn dod o hyd i nod Fersiwn, mae'n cymryd ei werth fel y fersiwn o'r pecyn sy'n cael ei adeiladu. Mae'n ymddangos, er mwyn adeiladu pecyn gyda fersiwn newydd, mae angen i chi naill ai ei ddiweddaru yn ffeil y prosiect neu ei basio fel dadl llinell orchymyn.

Gadewch i ni ychwanegu un Rhestr Ddymuniadau arall - gadewch i'r ddau rif lleiaf yn y fersiwn fod yn flwyddyn a dyddiad adeiladu'r pecyn, ac ychwanegu fersiynau rhag-ryddhau. Wrth gwrs, gallwch chi ychwanegu'r data hwn i ffeil y prosiect a gwirio cyn pob cyflwyniad - ond gallwch chi hefyd ei wneud ar y gweill, gan gasglu'r fersiwn pecyn o'r cyd-destun a'i basio trwy'r ddadl llinell orchymyn.

Gadewch i ni gytuno, os yw'r neges ymrwymo yn cynnwys llinell fel release (v./ver./version) <version number> (rev./revision <revision>)?, yna byddwn yn cymryd fersiwn y pecyn o'r llinell hon, yn ei ychwanegu at y dyddiad cyfredol ac yn ei drosglwyddo fel dadl i'r gorchymyn dotnet pack. Yn absenoldeb llinell, ni fyddwn yn casglu'r pecyn.

Mae'r sgript ganlynol yn datrys y broblem hon: 

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

Ychwanegu sgript at dasg pack and deploy job ac arsylwi ar y cydosod pecynnau yn llym ym mhresenoldeb llinyn penodol yn y neges ymrwymo.

Yn gyfan gwbl

Ar ôl treulio tua hanner awr neu awr yn ysgrifennu'r ffurfweddiad, dadfygio yn y plisgyn pwerau lleol ac, o bosibl, ychydig o lansiadau aflwyddiannus, cawsom gyfluniad syml ar gyfer awtomeiddio tasgau arferol.

Wrth gwrs, mae GitLab CI / CD yn llawer mwy helaeth ac amlochrog nag y gallai ymddangos ar ôl darllen y canllaw hwn - nid yw hynny'n wir o gwbl. Yno hyd yn oed Mae Auto DevOps yncaniatáu

canfod, adeiladu, profi, defnyddio a monitro eich cymwysiadau yn awtomatig

Nawr y cynlluniau yw ffurfweddu piblinell ar gyfer defnyddio cymwysiadau i Azure, gan ddefnyddio Pulumi a phennu'r amgylchedd targed yn awtomatig, a fydd yn cael sylw yn yr erthygl nesaf.

Ffynhonnell: hab.com

Ychwanegu sylw