Poznámka
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
Tento článek popisuje prostředky pro kanály YAML. Prostředek je cokoli, co používá pipeline a existuje mimo ni. Jakmile definujete prostředek, můžete ho využívat kdekoli ve vašem potrubí.
Prostředky poskytují úplnou sledovatelnost služeb, které vaše pipeline používá, včetně verze, artefaktů, přidružených commitů a pracovních položek. Pracovní postupy DevOps můžete plně automatizovat tím, že se přihlásíte k odběru spouštěcích událostí ve vašich prostředcích.
Schéma prostředků
Prostředky v YAML představují zdroje kanálů, buildů, úložišť, kontejnerů, balíčků a webhooků. Pro úplné informace o schématu se podívejte na definici prostředků v referenčních informacích ke schématu YAML pro Azure Pipelines.
Když prostředek aktivuje pipeline, nastaví se následující proměnné:
resources.triggeringAlias
resources.triggeringCategory
Aby se tyto hodnoty nastavily, musí být Build.Reason
proměnnáResourceTrigger
. Hodnoty jsou prázdné, pokud prostředek neaktivoval potrubí.
Definice zdroje Pipelines
Pokud máte kanál, který vytváří artefakty, můžete artefakty využívat definováním pipelines
prostředku. Azure Pipelines mohou používat pouze prostředek pipelines
. Triggery pro pracovní postupy průběžného nasazování (CD) můžete nastavit u kanálového prostředku.
V definici prostředku je pipeline
jedinečná hodnota, kterou můžete použít k odkazování na prostředek kanálu později v kanálu. Jedná se source
o název kanálu, který vytvořil artefakt kanálu. Úplné informace o schématu najdete v definici resources.pipelines.pipeline.
Použijete název definovaný pomocí pipeline
k odkazování na prostředek pipeline z jiných částí pipeline, například při použití proměnných prostředků pipeline nebo stahování artefaktů. Alternativní způsob stahování artefaktů kanálu najdete v tématu Stažení artefaktů.
Důležité
Při definování spouštěče zdroje pipeline:
-
pipeline
Pokud je prostředek ze stejného úložiště jako aktuální kanál, neboself
, spuštění sleduje stejnou větev a potvrzení, na kterých byla událost vyvolána. - Pokud prostředek kanálu pochází z jiného úložiště, aktuální kanál se aktivuje ve výchozí větvi
pipeline
úložiště prostředků.
Ukázkové definice prostředků pipeline
Následující příklad využívá artefakty z pipeline ve stejném projektu.
resources:
pipelines:
- pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
source: SmartHotel-CI # name of the pipeline that produces the artifacts
Pokud chcete získat přístup k pipeline z jiného projektu, zahrnete název projektu a název zdroje. Následující příklad používá branch
k vyřešení výchozí verze při ručním nebo naplánovaném spuštění kanálu. Vstup větve nemůže obsahovat zástupné znaky.
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
branch: releases/M142
Následující příklad ukazuje prostředek kanálu s jednoduchým triggerem.
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger: true
Následující příklad ukazuje zdroj pipeline trigger
s podmínkami větví.
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger:
branches:
- releases/*
- resources.triggeringAlias
Následující příklad používá stages
filtry k vyhodnocení podmínek spuštění pro CD pipelines. Fáze používají AND
operátor. Po úspěšném dokončení všech zadaných etap se aktivuje CD pipeline.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
trigger:
stages:
- PreProduction
- Production
Následující příklad používá tags
filtry pro vyhodnocení výchozí verze a pro triggery. Značky používají AND
operátor.
Na kanálu kontinuální integrace (CI) nebo CD jsou nastaveny tags
. Tyto značky se liší od značek nastavených ve větvích v úložišti Git.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
tags:
- Production
trigger:
tags:
- Production
- Signed
Vyhodnocení verze artefaktu potrubí
Verze artefaktu potrubí prostředku závisí na tom, jak se potrubí spustí.
Ruční nebo naplánovaná aktivační událost
Pokud je spuštění kanálu ručně aktivováno nebo naplánováno, hodnoty version
, branch
a tags
vlastnosti definují verzi artefaktu. Vstup branch
nemůže obsahovat zástupné znaky. Vlastnosti tags
používají AND
operátor.
Zadané vlastnosti | Verze artefaktu |
---|---|
version |
Artefakty ze sestavení, které mají zadané číslo spuštění |
branch |
Artefakty z nejnovějšího sestavení provedeného v zadané větvi |
tags seznam |
Artefakty z nejnovější verze, které mají všechny zadané značky |
branch a tags seznam |
Artefakty z nejnovějšího sestavení provedeného v zadané větvi, která má všechny zadané značky |
version a branch |
Artefakty z buildu se specifikovaným číslem spuštění a specifikovanou větví. |
Nic | Artefakty z nejnovějšího buildu ve všech větvích |
Následující pipeline
definice zdroje používá vlastnosti branch
a tags
k vyhodnocení výchozí verze při ručním nebo plánovaném spuštění pipeline. Když ručně spustíte potrubí, verze artefaktů potrubí je nejnovější build provedený na větvi MyCIAlias
, která má značky main
a Production
.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
branch: main
tags:
- Production
- PreProduction
Aktivace dokončení potrubí zdrojů
Když se potrubí aktivuje, protože jeden z jeho potrubí prostředků je dokončen, verze artefaktů je verze spouštěcího potrubí. Hodnoty objektu version
, branch
a tags
vlastnosti jsou ignorovány.
Zadané spouštěče | Výsledek |
---|---|
branches |
Nové spuštění potrubí se aktivuje vždy, když potrubí prostředků úspěšně dokončí spuštění na jedné z include větví. |
tags |
Nové spuštění kanálu se aktivuje pokaždé, když zdrojový kanál úspěšně dokončí spuštění označené všemi specifikovanými značkami. |
stages |
Nové spuštění kanálu se spustí při každém úspěšném provedení zadaného kanálu prostředku stages . |
branches , tags , a stages |
Nové spuštění kanálu se spustí pokaždé, když spuštění kanálu zdrojů splňuje všechny podmínky větve, značek a fází. |
trigger: true |
Nové spuštění pipeline se aktivuje pokaždé, když se pipeline zdroje úspěšně dokončí. |
Nic | Po úspěšném dokončení spuštění zdrojového kanálu se nespustí žádné nové spuštění kanálu. |
Následující potrubí se spustí, kdykoli se aktivuje potrubí prostředku SmartHotel-CI
.
- Funguje na jedné z
releases
větví nebo vemain
větvi. - Je označený oběma
Verified
aSigned
- Dokončí jak fázi
Production
, tak fáziPreProduction
.
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger:
branches:
include:
- releases/*
- main
exclude:
- topic/*
tags:
- Verified
- Signed
stages:
- Production
- PreProduction
Stažení artefaktů potrubí
Krok download
stáhne artefakty přidružené k aktuálnímu běhu nebo k jinému kanálovému prostředku.
Všechny artefakty z aktuálního potrubí a všechny jeho pipeline
prostředky se automaticky stáhnou a zpřístupní na začátku každé úlohy nasazení. Toto chování můžete přepsat nastavením download
na none
nebo zadáním jiného identifikátoru prostředku pipeline.
Artefakty běžných úloh se nestáhnou automaticky. Explicitně použijte download
v případě potřeby.
Artefakty z pipeline
prostředku se stáhnou do $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> složky. Pro více informací se podívejte na Publikování a stahování artefaktů pipeline.
Volitelná artifact
vlastnost určuje názvy artefaktů. Pokud není zadaný, stáhnou se všechny dostupné artefakty. Volitelná patterns
vlastnost definuje vzory, které představují soubory, které se mají zahrnout. Úplné informace o schématu najdete v definici steps.download.
- job: deploy_windows_x86_agent
steps:
- download: SmartHotel
artifact: WebTier1
patterns: '**/*.zip'
Proměnné zdrojů kanálu
V každém spuštění jsou metadata zdroje pipeline k dispozici pro všechny úlohy jako předdefinované proměnné. Tyto proměnné jsou k dispozici pro váš kanál pouze za běhu, a proto je nelze použít ve výrazech šablony, které se vyhodnocují v době kompilace kanálu.
Další informace najdete v tématu Metadata prostředků kanálu jako předdefinované proměnné. Další informace o syntaxi proměnných najdete v tématu Definování proměnných.
Příklad níže vrátí předdefinované hodnoty proměnných pro zdroj kanálu myresourcevars
.
resources:
pipelines:
- pipeline: myresourcevars
source: mypipeline
trigger: true
steps:
- script: |
echo $(resources.pipeline.myresourcevars.pipelineID)
echo $(resources.pipeline.myresourcevars.runName)
echo $(resources.pipeline.myresourcevars.runID)
echo $(resources.pipeline.myresourcevars.runURI)
echo $(resources.pipeline.myresourcevars.sourceBranch)
echo $(resources.pipeline.myresourcevars.sourceCommit)
echo $(resources.pipeline.myresourcevars.sourceProvider)
echo $(resources.pipeline.myresourcevars.requestedFor)
echo $(resources.pipeline.myresourcevars.requestedForID)
Vytváření definice prostředku
Pokud máte externí systém sestavení CI, který vytváří artefakty, můžete artefakty zpracovat pomocí prostředků builds
. Prostředek build
může být z libovolného externího systému CI, jako je Jenkins, TeamCity nebo CircleCI.
Kategorie builds
je rozšiřitelná. Můžete napsat rozšíření pro spotřebovávání artefaktů ze služby sestavení a zároveň zavést nový typ služby jako součást builds
.
build
V definici version
se ve výchozím nastavení nastaví nejnovější úspěšné sestavení.
trigger
není ve výchozím nastavení povoleno a musí být explicitně nastaveno. Úplné informace o schématu najdete v definici resources.builds.build.
V následujícím příkladu je Jenkins zdrojem type
.
resources:
builds:
- build: Spaceworkz
type: Jenkins
connection: MyJenkinsServer
source: SpaceworkzProj # name of the Jenkins source project
trigger: true
Důležité
Spouštěče se podporují jenom pro hostovaný Jenkins, kde má Azure DevOps přímý přístup k serveru Jenkins.
Úloha downloadBuild
Artefakty build
prostředků se ve vašich úlohách nebo úlohách deploy-jobs nestáhnou automaticky. Pokud chcete využívat artefakty z build
prostředku jako součást svých úloh, musíte explicitně přidat úlohu downloadBuild
. Můžete přizpůsobit chování stahování pro každé nasazení nebo úlohu.
Tato úloha se automaticky přeloží na odpovídající úlohu stahování pro typ build
prostředku, který modul runtime definuje. Artefakty z build
prostředku se stáhnou do $(PIPELINE.WORKSPACE)/<build-identifier>/ složky.
downloadBuild
V definici zadáte prostředek, ze kterém se mají stahovat artefakty. Volitelná artifact
vlastnost určuje artefakty ke stažení. Pokud není zadáno, stáhnou se všechny artefakty přidružené k prostředku.
Volitelná patterns
vlastnost určuje cestu minimatch nebo seznam cest minimatch ke stažení. Pokud je prázdný, stáhne se celý artefakt. Například následující fragment kódu stáhne pouze soubory *.zip .
- job: deploy_windows_x86_agent
steps:
- downloadBuild: Spaceworkz
patterns: '**/*.zip'
Úplné informace o schématu najdete v definici steps.downloadBuild.
Definice prostředku úložiště
Klíčové repository
slovo umožňuje zadat externí úložiště. Tento prostředek můžete použít, pokud váš kanál sestavení obsahuje šablony v jiném úložišti nebo chcete použít multi-repo checkout s úložištěm, které vyžaduje připojení služby. Musíte dát systému vědět o těchto úložištích.
Příklad:
resources:
repositories:
- repository: common
type: github
name: Contoso/CommonTools
endpoint: MyContosoServiceConnection
Úplné informace o schématu najdete v definici resources.repositories.repository.
Typy prostředků úložiště
Azure Pipelines podporuje následující hodnoty pro typ úložiště: git
, github
, githubenterprise
a bitbucket
.
- Typ
git
odkazuje na úložiště Git v Azure Repos. - Úložiště GitHub Enterprise vyžadují pro autorizaci připojení služby GitHub Enterprise.
- Úložiště Bitbucket Cloud vyžadují pro autorizaci připojení ke cloudové službě Bitbucket.
Typ | Hodnota názvu | Příklad |
---|---|---|
type: git |
Jiné úložiště ve stejném projektu nebo stejné organizaci. | Stejný projekt: name: otherRepo Jiný projekt ve stejné organizaci: name: otherProject/otherRepo . |
type: github |
Úplný název úložiště GitHub, včetně uživatele nebo organizace. | name: Microsoft/vscode |
type: githubenterprise |
Úplný název úložiště GitHub Enterprise, včetně uživatele nebo organizace. | name: Microsoft/vscode |
type: bitbucket |
Úplný název úložiště Bitbucket Cloud včetně uživatele nebo organizace. | name: MyBitbucket/vscode |
Proměnné prostředků úložiště
Při každém spuštění jsou následující metadata zdroje úložiště k dispozici všem úlohám ve formě proměnných za běhu.
<Alias>
je identifikátor, který dáte prostředku úložiště.
resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
Následující příklad obsahuje prostředek úložiště s aliasem common
, takže proměnné prostředků úložiště jsou přístupné pomocí resources.repositories.common.*
.
resources:
repositories:
- repository: common
type: git
ref: main
name: Repo
variables:
ref: $[ resources.repositories.common.ref ]
name: $[ resources.repositories.common.name ]
id: $[ resources.repositories.common.id ]
type: $[ resources.repositories.common.type ]
url: $[ resources.repositories.common.url ]
steps:
- bash: |
echo "name = $(name)"
echo "ref = $(ref)"
echo "id = $(id)"
echo "type = $(type)"
echo "url = $(url)"
Při každém spuštění jsou následující metadata zdroje úložiště k dispozici všem úlohám ve formě proměnných za běhu.
<Alias>
je identifikátor, který dáte prostředku úložiště.
resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
resources.repositories.<Alias>.version
Následující příklad obsahuje prostředek úložiště s aliasem common
, takže proměnné prostředků úložiště jsou přístupné pomocí resources.repositories.common.*
.
resources:
repositories:
- repository: common
type: git
ref: main
name: Repo
variables:
ref: $[ resources.repositories.common.ref ]
name: $[ resources.repositories.common.name ]
id: $[ resources.repositories.common.id ]
type: $[ resources.repositories.common.type ]
url: $[ resources.repositories.common.url ]
version: $[ resources.repositories.common.version ]
steps:
- bash: |
echo "name = $(name)"
echo "ref = $(ref)"
echo "id = $(id)"
echo "type = $(type)"
echo "url = $(url)"
echo "version = $(version)"
Klíčové slovo pro přístup k repozitářům
Repozitáře z repository
prostředku nejsou ve vašich úlohách automaticky synchronizovány. Použijte klíčové slovo checkout
k načtení úložiště definovaného jako součást zdroje repository
. Úplné informace o schématu najdete v definici steps.checkout.
Další informace najdete v tématu Prohlédněte si více úložišť ve svém kanálu.
Definice prostředků kontejnerů
Pokud potřebujete využívat image kontejnerů jako součást CI/CD pipeline, můžete použít containers
prostředky. Prostředek container
může být veřejný nebo privátní registr Dockeru nebo instance služby Azure Container Registry.
Jako součást úlohy můžete použít obecný obraz prostředku kontejneru nebo tento prostředek využít pro kontejnerové úlohy. Pokud váš kanál vyžaduje podporu jedné nebo více služeb, musíte vytvořit a připojit se ke kontejnerům služeb. Můžete použít svazky ke sdílení dat mezi službami.
Pokud potřebujete využívat obrazy z registru Dockeru jako součást vývojové linky, můžete definovat obecný prostředek kontejneru. Není vyžadováno žádné type
klíčové slovo. Příklad:
resources:
containers:
- container: smartHotel
endpoint: myDockerRegistry
image: smartHotelApp
Úplné informace o schématu najdete v definici resources.containers.container.
Poznámka:
Syntaxe enabled: 'true'
pro povolení triggerů kontejneru pro všechny značky obrazů se liší od syntaxe pro jiné triggery prostředků. Nezapomeňte použít správnou syntaxi pro konkrétní prostředky.
Typ prostředku Azure Container Registry
Pokud chcete spotřebovávat image služby Azure Container Registry, můžete použít typ prostředku první třídy acr
kontejneru. Tento typ prostředku můžete použít jako součást svých pracovních úkolů a povolit automatické spouštění pipeline.
K používání kanálu s automatickými spouštěči potřebujete oprávnění přispěvatele nebo vlastníka služby Azure Container Registry. Další informace najdete v tématu Role a oprávnění služby Azure Container Registry.
Pokud chcete použít typ prostředku acr
, musíte specifikovat hodnoty azureSubscription
, resourceGroup
, a repository
pro váš Azure registr kontejnerů. Příklad:
resources:
containers:
- container: petStore
type: acr
azureSubscription: ContosoConnection
resourceGroup: ContosoGroup
registry: petStoreRegistry
repository: myPets
trigger:
tags:
include:
- production*
Poznámka:
Vyhodnocení triggeru probíhá pouze ve výchozí větvi. Nezapomeňte nastavit správnou výchozí větev nebo sloučit soubor YAML do aktuální výchozí větve. Další informace o tom, jak změnit výchozí větev kanálu, najdete v části Výchozí větev kanálu.
Proměnné prostředků kontejneru
Po definování kontejneru jako prostředku se metadata kontejnerového obrazu předají kanálu jako proměnné. Informace, jako jsou image, registr a podrobnosti o připojení, jsou přístupné napříč všemi úlohami použitými v úlohách nasazení kontejneru.
Proměnné prostředků kontejneru fungují s Dockerem a službou Azure Container Registry. Nemůžete použít proměnné prostředků kontejneru pro lokální image kontejnery. Proměnná location
se vztahuje pouze na acr
typ prostředků kontejneru.
Následující příklad obsahuje připojení služby Azure Resource Manager s názvem arm-connection
. Další informace najdete v tématu Registry kontejnerů, úložiště a image Azure.
resources:
containers:
- container: mycontainer
type: ACR
azureSubscription: arm-connection
resourceGroup: rg-storage-eastus
registry: mycontainerregistry
repository: hello-world
trigger:
tags:
- latest
steps:
- script: echo |
echo $(resources.container.mycontainer.type)
echo $(resources.container.mycontainer.registry)
echo $(resources.container.mycontainer.repository)
echo $(resources.container.mycontainer.tag)
echo $(resources.container.mycontainer.digest)
echo $(resources.container.mycontainer.URI)
echo $(resources.container.mycontainer.location)
Definice zdroje balíčků
Balíčky NuGet a npm GitHubu můžete využívat jako zdroje v pipelinách YAML. Pokud chcete povolit automatické triggery kanálu při vydání nové verze balíčku, nastavte vlastnost trigger
na true
.
Při definování package
prostředků zadejte do vlastnosti úložiště<>/název<> balíčku name
a nastavte balíček type
jako NuGet
nebo npm
. Pokud chcete používat balíčky GitHub, použijte ověřování na základě PAT a vytvořte připojení ke službě GitHub, které používá PAT.
Úplné informace o schématu naleznete v definici resources.packages.package.
Ve výchozím nastavení se balíčky automaticky nestáhnou do úloh. Ke stažení použijte getPackage.
Následující příklad obsahuje GitHub service connection pojmenované pat-contoso
a GitHub npm balíček pojmenovaný contoso
. Další informace najdete v balíčcích GitHubu.
resources:
packages:
- package: contoso
type: npm
connection: pat-contoso
name: myname/contoso
version: 7.130.88
trigger: true
pool:
vmImage: 'ubuntu-latest'
steps:
- getPackage: contoso
Definice prostředku Webhook
Poznámka:
Webhooky byly vydány ve Azure DevOps Serveru 2020.1.
Artefakty můžete využívat a povolit automatizované triggery s prostředky kanálu, kontejneru, sestavení a balíčku. Tyto prostředky ale nemůžete použít k automatizaci nasazení na základě externích událostí nebo služeb.
Prostředek webhooks
v kanálech YAML umožňuje integrovat vaše kanály s externími službami, jako jsou GitHub, GitHub Enterprise, Nexus a Artifactory, a automatizovat pracovní postupy. Můžete se přihlásit k odběru jakýchkoli externích událostí prostřednictvím webhooků a pomocí událostí aktivovat vaše kanály.
Webhooky automatizují váš pracovní postup na základě jakékoli externí události webhooku, která není podporována prvotřídními zdroji, jako jsou kanály, buildy, kontejnery nebo balíčky. U místních služeb, kde Azure DevOps nemá přehled o procesu, můžete také nakonfigurovat webhooky ve službě a aktivovat kanály automaticky.
Pokud se chcete přihlásit k odběru události webhooku, definujete prostředek webhooku ve vašem pipeline a nasměrujete ho na příchozí připojení ke službě webhooku. Můžete také definovat další filtry pro prostředek webhooku na základě dat JSON, abyste přizpůsobili spouštěče pro každé potrubí.
Pokaždé, když příchozí připojení služby webhooku obdrží událost webhooku, spustí se nový běh pro všechny pipelines, které se přihlásily k odběru události webhooku. Data datové části JSON můžete ve svých úlohách využívat jako proměnné pomocí formátu ${{ parameters.<WebhookAlias>.<JSONPath>}}
.
Úplné informace o schématu najdete v definici resources.webhooks.webhook.
Následující příklad definuje zdroj webhooku:
resources:
webhooks:
- webhook: WebHook
connection: IncomingWH
steps:
- script: echo ${{ parameters.WebHook.resource.message.title }}
Spouštěče webhooku
Pokud chcete nakonfigurovat triggery webhooku, nejprve ve své externí službě nastavíte webhook s následujícími informacemi:
-
Adresa URL požadavku:
https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
- Tajný klíč (volitelné): Pokud potřebujete datovou část JSON zabezpečit, zadejte hodnotu tajného kódu.
Dále vytvoříte nové příchozí připojení služby webhooku. Pro tento typ připojení služby definujete následující informace:
- Název webhooku: Stejný jako webhook vytvořený ve vaší externí službě.
- Tajný kód (volitelné): Slouží k ověření hodnoty hash HMAC-SHA1 datové části pro ověření příchozího požadavku. Pokud jste při vytváření webhooku použili tajný kód, musíte zadat stejný tajný kód.
-
Hlavička HTTP: Hlavička HTTP v požadavku, která obsahuje hodnotu hash HMAC-SHA1 datové části pro ověření požadavku. Například hlavička požadavku GitHubu je
X-Hub-Signature
.
K aktivaci potrubí pomocí webhooku provedete POST
požadavek na https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview
. Tento koncový bod je veřejně dostupný a nepotřebuje žádnou autorizaci. Požadavek by měl mít text podobný následujícímu příkladu:
{
"resource": {
"message": {
"title": "Hello, world!",
"subtitle": "I'm using WebHooks!"
}
}
}
Poznámka:
Přístup k datům z textu požadavku webhooku může vést k nesprávnému YAML. Například krok kanálu - script: echo ${{ parameters.WebHook.resource.message }}
načítá celou zprávu JSON, což vede ke generování neplatného YAML. Žádný kanál aktivovaný prostřednictvím tohoto webhooku se nespustí, protože vygenerovaný YAML začal být neplatný.
Následující fragment kódu ukazuje další příklad, který používá filtry webhooku.
resources:
webhooks:
- webhook: MyWebhookTrigger
connection: MyWebhookConnection
filters:
- path: repositoryName
value: maven-releases
- path: action
value: CREATED
steps:
- task: PowerShell@2
inputs:
targetType: 'inline'
script: |
Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
Ruční výběr verzí pro prostředky
Když ručně aktivujete kanál CD YAML, Azure Pipelines automaticky vyhodnotí výchozí verze pro prostředky definované v kanálu na základě zadaných vstupů. Azure Pipelines ale při vyhodnocování výchozí verze pro plánované aktivační události bere v úvahu pouze úspěšná spuštění CI, nebo pokud verzi nevyberete ručně.
Pomocí nástroje volby verze prostředku můžete při zahájení běhu ručně zvolit jinou verzi. Výběr verze prostředku je podporovaný pro prostředky pipeline, sestavení, úložiště, kontejner a balíček.
U zdrojů potrubí můžete zobrazit všechna dostupná spuštění ve všech větvích, vyhledávat je podle čísla potrubí nebo větve a vybrat spuštění, které je úspěšné, neúspěšné nebo probíhající. Tato flexibilita zajišťuje, že můžete spustit CD kanál, pokud jste si jistí, že běh vytvořil všechny potřebné artefakty. Nemusíte čekat na dokončení běhu CI nebo jej znovu spustit kvůli selhání nesouvisející fáze.
Pokud chcete použít výběr verze prostředku, vyberte v podokně Spustit kanálProstředky, pak vyberte prostředek a v seznamu dostupných verzí vyberte konkrétní verzi.
Pro prostředky, kde nemůžete načíst dostupné verze, jako jsou balíčky na GitHub, výběr verze obsahuje textové pole, abyste mohli zadat verzi, kterou má použít při spuštění.
Autorizace prostředků v YAML pipelinech
Prostředky musí být autorizované, aby je bylo možné použít v kanálech. Vlastníci prostředků řídí uživatele a kanály, které mají přístup ke svým prostředkům. Existuje několik způsobů, jak autorizovat kanál YAML k použití prostředků.
Pomocí prostředí pro správu prostředků můžete autorizovat všechny kanály pro přístup k prostředku. Například skupiny proměnných a zabezpečené soubory se spravují na stránce Knihovna v části Kanály, a fondy agentů a připojení služeb se spravují v Nastavení projektu. Tato autorizace je praktická, pokud nepotřebujete omezit přístup k prostředkům, jako jsou testovací prostředky.
Při vytváření kanálu jsou všechny prostředky odkazované v souboru YAML automaticky autorizované k použití kanálem, pokud pro tyto prostředky máte roli Uživatel .
Pokud do souboru YAML přidáte prostředek a sestavení selže s chybou, jako je
Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.
, zobrazí se možnost autorizovat prostředky u neúspěšného sestavení.Pokud máte roli Uživatele pro prostředek, můžete tuto možnost vybrat a autorizovat prostředek pro neúspěšné sestavení. Jakmile je zdroj autorizován, můžete spustit nové sestavení.
Zkontrolujte, zda jsou role zabezpečení ve fondu agentů pro váš projekt správné.
Kontroly schvalování zdrojů
Kontroly schválení a šablony můžete použít k tomu, abyste ručně řídili, kdy se prostředek spustí. Pomocí kontroly schválení požadované šablony můžete vyžadovat, aby jakákoli pipelina využívající prostředek nebo prostředí využívala konkrétní šablonu YAML.
Nastavení požadovaného schválení šablony zajistí, že se váš prostředek použije jenom za určitých podmínek, a zlepší zabezpečení. Další informace o vylepšení zabezpečení kanálů pomocí šablon najdete v tématu Použití šablon pro zabezpečení.
Sledovatelnost
Azure Pipelines poskytuje úplnou sledovatelnost všech prostředků spotřebovaných na úrovni pipelines nebo úrovni úlohy nasazení.
Sledovatelnost kanálu
Azure Pipelines zobrazuje následující informace pro každý běh potrubí:
- Pokud prostředek aktivoval kanál, prostředek, který kanál aktivoval.
- Verze zdroje a artefakty, které byly spotřebovány.
- Změny přidružené k jednotlivým prostředkům.
- Pracovní položky přidružené ke každému zdroji
Sledovatelnost prostředí
Pokaždé, když se pipeline nasadí do prostředí, zobrazí se seznam využívaných zdrojů. Zobrazení zahrnuje prostředky spotřebované jako součást úloh nasazení a s nimi spojená potvrzení a pracovní položky.
Informace o přidružených kanálech CD v kanálech CI
Pokud chcete zajistit kompletní sledovatelnost, můžete sledovat, které kanály CD využívají konkrétní kanál CI prostřednictvím pipelines
prostředku. Pokud jiné kanály využívají váš CI kanál, zobrazí se v zobrazení Spustit karta Přidružené kanály. V zobrazení se zobrazí všechna spuštění kanálu YAML CD, která kanál CI spotřebovala, a artefakty z něj.
Problémy se spouštěním prostředků
Spouštěče prostředků se nedají spustit, protože:
- Zdroj poskytnutého připojení služby je neplatný, v triggeru jsou chyby syntaxe nebo trigger není nakonfigurovaný.
- Podmínky triggeru se neshodují.
Pokud chcete zjistit, proč se triggery v potrubí nepodařilo spustit, vyberte položku nabídky Problémy s triggery na stránce definice potrubí. Problematika triggerů je k dispozici pouze pro prostředky mimo repozitář.
Na stránce Problémy s triggerem chybové zprávy a upozornění popisují, proč se trigger nezdařil.
Často kladené dotazy
Kdy mám použít prostředky kanálů, zástupce pro stažení nebo úlohu Stáhnout artefakty kanálu?
Použití prostředku pipelines
je způsob, jak využívat artefakty z CI pipeline a také nastavit automatizované triggery. Prostředek poskytuje úplný přehled o procesu zobrazením spotřebované verze, artefaktů, potvrzení a pracovních položek. Když definujete prostředek pipeline, přidružené artefakty se automaticky stáhnou v úlohách nasazení.
Zkratku download
můžete použít ke stažení artefaktů v úlohách sestavení nebo k úpravě způsobu stahování v úlohách nasazení. Další informace najdete v definici steps.download.
Úloha stažení artefaktů kanálu neposkytuje sledovatelnost ani aktivátory, ale někdy má smysl tuto úlohu použít přímo. Můžete mít například úlohu skriptu uloženou v jiné šabloně, která vyžaduje stažení artefaktů z sestavení. Nebo třeba nebudete chtít přidat prostředek kanálu do šablony. Abyste se vyhnuli závislostem, můžete použít úlohu Stažení artefaktů kanálu k předání všech informací o sestavení na úkol.
Jak mohu spustit pipeline, když se aktualizuje image na Docker Hubu?
Trigger kontejnerového prostředku není k dispozici pro Docker Hub na YAML potrubích, takže je potřeba nastavit klasické potrubí vydání.
- Vytvořte nové připojení služby Docker Hub.
- Vytvořte klasické vydávací potrubí a přidejte artefakt z Docker Hubu. Nastavte připojení služby a vyberte obor názvů, úložiště, verzi a alias zdroje.
- Vyberte spouštěč a přepněte spouštěč průběžného nasazování na Povolit. Každé nahrání Dockeru do vybraného úložiště vytvoří vydání.
- Vytvořte novou fázi a úlohu. Přidejte dva úkoly, přihlášení Dockeru a Bash.
- Úloha Dockeru má akci
login
a přihlásí vás k Docker Hubu. - Úloha Bash běží
docker pull <hub-user>/<repo-name>[:<tag>]
.
- Úloha Dockeru má akci
Jak mohu ověřit a odstraňovat problémy u svého webhooku?
Vytvořte připojení služby.
Odkazujte na připojení ke službě a pojmenujte webhook v části
webhooks
.resources: webhooks: - webhook: MyWebhookTriggerAlias connection: MyServiceConnection
Spusťte potrubí. Webhook se vytvoří v Azure jako distribuovaný úkol pro vaši organizaci.
POST
Proveďte volání rozhraní API s platným kódem JSON v textu dohttps://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>
. Pokud obdržíte odpověď s kódem stavu 200, váš webhook je připravený pro použití ve vašem kanálu.
Pokud se zobrazí odpověď se stavovým kódem 500 s chybou Cannot find webhook for the given webHookId ...
, váš kód může být ve větvi, která není vaší výchozí větví. Tento problém vyřešíte takto:
- Na stránce potrubí vyberte Upravit.
- V nabídce Další akce vyberte Aktivační události.
- Vyberte kartu YAML a pak vyberte Získat zdroje.
- V části Výchozí větev pro ruční a naplánované sestavení aktualizujte větev funkcí.
- Vyberte Uložit a zařadit do fronty.
- Po úspěšném spuštění tohoto pipeline proveďte
POST
volání rozhraní API s platným JSON obsahem nahttps://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>
. Teď byste měli obdržet odpověď na stavový kód 200.