Prostředky v kanálech YAML
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á kanál, který existuje mimo kanál. Jakmile definujete prostředek, můžete ho využívat kdekoli ve svém kanálu.
Prostředky poskytují úplnou sledovatelnost služeb, které kanál používá, včetně verze, artefaktů, přidružených potvrzení a pracovních položek. Pracovní postupy DevOps můžete plně automatizovat tak, že se přihlašujete k odběru 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ů. Úplné informace o schématu najdete v definici prostředků v referenčních informacích ke schématu YAML pro Azure Pipelines.
Když prostředek aktivuje kanál, nastaví se následující proměnné:
resources.triggeringAlias
resources.triggeringCategory
Aby se tyto hodnoty nastavily, musí být ResourceTrigger
proměnnáBuild.Reason
. Hodnoty jsou prázdné, pokud prostředek neaktivoval spuštění kanálu.
Definice prostředku Pipelines
Pokud máte kanál, který vytváří artefakty, můžete artefakty využívat definováním pipelines
prostředku. Prostředek může používat pipelines
pouze Azure Pipelines. Triggery pro pracovní postupy průběžného nasazování (CD) můžete nastavit u prostředku kanálu.
V definici prostředku je jedinečná hodnota, pipeline
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 kanálu resources.pipelines.pipeline.
Popisek definovaný pomocí pipeline
odkazu na prostředek kanálu z jiných částí kanálu, například při použití proměnných prostředků kanálu 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í triggeru prostředku kanálu:
pipeline
Pokud je prostředek ze stejného úložiště jako aktuální kanál, neboself
se aktivuje stejnou větev a potvrzení, u kterého je 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ů kanálu
Následující příklad využívá artefakty z kanálu 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 kanál využívat 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é cardy.
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 prostředek trigger
kanálu s podmínkami větve.
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger:
branches:
- releases/*
- resources.triggeringAlias
Následující příklad používá stages
filtry pro vyhodnocení podmínek triggeru pro kanály CD. Fáze používají AND
operátor. Po úspěšném dokončení všech zadaných fází se aktivuje kanál CD.
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.
Jsou tags
nastavené v kanálu kontinuální integrace (CI) nebo CD. 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 artefaktů kanálů
Verze artefaktu kanálu prostředku závisí na tom, jak se kanál aktivuje.
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é cardy. Vlastnosti tags
používají AND
operátor.
Zadané vlastnosti | Verze artefaktu |
---|---|
version |
Artefakty z 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šího sestavení, 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 |
Nic | Artefakty z nejnovějšího sestavení ve všech větvích |
Následující pipeline
definice prostředku používá branch
vlastnosti a tags
vlastnosti k vyhodnocení výchozí verze při ručním nebo plánovaném spuštění kanálu. Když ručně aktivujete spuštění kanálu, MyCIAlias
verze artefaktů kanálu je nejnovější build provedený ve main
větvi, která obsahuje značky Production
a PrepProduction
značky.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
branch: main
tags:
- Production
- PreProduction
Aktivační událost dokončení kanálu prostředku
Když se kanál aktivuje kvůli dokončení jednoho z jeho kanálů prostředků, verze artefaktů je verze aktivačního kanálu. Hodnoty objektu version
, branch
a tags
vlastnosti jsou ignorovány.
Zadané triggery | Výsledek |
---|---|
branches |
Nové spuštění kanálu se aktivuje vždy, když kanál prostředku úspěšně dokončí spuštění na jedné z include větví. |
tags |
Nové spuštění kanálu se aktivuje pokaždé, když kanál prostředku úspěšně dokončí spuštění označené všemi zadanými značkami. |
stages |
Nové spuštění kanálu se aktivuje při každém úspěšném spuštění kanálu prostředku zadaného stages kanálu . |
branches , tags a stages |
Nové spuštění kanálu se aktivuje pokaždé, když spuštění kanálu prostředků splňuje všechny podmínky větve, značek a fází. |
trigger: true |
Nové spuštění kanálu se aktivuje pokaždé, když kanál prostředku úspěšně dokončí spuštění. |
Nic | Po úspěšném dokončení spuštění kanálu se neaktivuje žádné nové spuštění kanálu. |
Následující kanál se spustí při každém SmartHotel-CI
spuštění kanálu prostředku:
- Běží na jedné z
releases
větví nebo vemain
větvi. - Je označený oběma
Verified
aSigned
- Dokončí jak fáze, tak
Production
PreProduction
i fáze.
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ů kanálu
Krok download
stáhne artefakty přidružené k aktuálnímu spuštění nebo jinému prostředku kanálu.
Všechny artefakty z aktuálního kanálu a všech jejích pipeline
prostředků 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
hodnotu nebo zadáním jiného identifikátoru prostředku kanálu.
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> folder. Další informace najdete v tématu Publikování a stahování artefaktů kanálu.
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é prostředků kanálu
V každém spuštění jsou metadata prostředku kanálu 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.
Následující příklad vrátí předdefinované hodnoty proměnných myresourcevars
pro prostředek kanálu.
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)
Sestavení definice prostředku
Pokud máte externí systém sestavení CI, který vytváří artefakty, můžete využívat artefakty s builds
prostředky. 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 využívání artefaktů ze služby sestavení a 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í. Ve trigger
výchozím nastavení není povolená a musí být explicitně nastavená. Úplné informace o schématu najdete v definici resources.builds.build.
V následujícím příkladu je Jenkins prostředkem type
.
resources:
builds:
- build: Spaceworkz
type: Jenkins
connection: MyJenkinsServer
source: SpaceworkzProj # name of the Jenkins source project
trigger: true
Důležité
Triggery se podporují jenom pro hostované Jenkinse, kde má Azure DevOps přehled se serverem Jenkinse.
Ú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 úloh, musíte úkol explicitně přidat downloadBuild
. Chování stahování pro každé nasazení nebo úlohu můžete přizpůsobit.
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>/ folder.
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í zadaný, stáhnou se všechny artefakty přidružené k prostředku.
Volitelná patterns
vlastnost definuje 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 obsahuje šablony v jiném úložišti nebo chcete použít rezervaci s více úložišti 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ě
V každém spuštění jsou pro všechny úlohy ve formě proměnných modulu runtime k dispozici následující metadata prostředku úložiště. Jedná se <Alias>
o 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)"
V každém spuštění jsou pro všechny úlohy ve formě proměnných modulu runtime k dispozici následující metadata prostředku úložiště. Jedná se <Alias>
o 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 rezervace úložišť
Úložiště z repository
prostředku se ve vašich úlohách automaticky nesynchronizují. checkout
Klíčové slovo použijte k načtení úložiště definovaného repository
jako součást prostředku. Úplné informace o schématu najdete v definici steps.checkout.
Další informace najdete v tématu Rezervace více úložišť v kanálu.
Definice prostředku kontejnerů
Pokud potřebujete využívat image kontejnerů jako součást kanálů CI/CD, 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 obecnou image prostředku kontejneru nebo použít prostředek pro úlohy kontejneru. Pokud váš kanál vyžaduje podporu jedné nebo více služeb, musíte vytvořit kontejnery služeb a připojit se k němu. Svazky můžete použít ke sdílení dat mezi službami.
Pokud potřebujete využívat image z registru Dockeru jako součást kanálu, 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 image se liší od syntaxe pro jiné triggery prostředků. Nezapomeňte použít správnou syntaxi pro konkrétní prostředky.
Typ prostředku služby Azure Container Registry
Pokud chcete využívat image služby Azure Container Registry, můžete použít typ acr
prostředku kontejneru první třídy . Tento typ prostředku můžete použít jako součást úloh a povolit automatické aktivační události kanálu.
K používání automatických triggerů kanálu 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 acr
typ prostředku, musíte zadat hodnotu a resourceGroup
repository
hodnoty registru kontejneru azureSubscription
Azure. Příklad:
resources:
containers:
- container: petStore
type: acr
azureSubscription: ContosoConnection
resourceGroup: ContosoGroup
registry: petStoreRegistry
repository: myPets
trigger:
tags:
include:
- production*
Poznámka:
Připojení služeb, která používají federaci identit úloh, nejsou podporována v azureSubscription
.
Proměnné prostředků kontejneru
Po definování kontejneru jako prostředku se metadata image kontejneru předá 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. Proměnné prostředků kontejneru nemůžete použít pro místní kontejnery imagí. 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 prostředku packages
Balíčky NuGet a npm GitHubu můžete využívat jako prostředky v kanálech YAML. Pokud chcete povolit automatické aktivační události kanálu při vydání nové verze balíčku, nastavte trigger
vlastnost na true
.
Při definování package
prostředků zadejte do vlastnosti úložiště></název> name
balíčku <a nastavte balíček type
jako NuGet
nebo npm
. Pokud chcete používat balíčky GitHubu, použijte ověřování na základě pat a vytvořte připojení služby GitHub, které používá token 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 připojení služby GitHub s názvem pat-contoso
k balíčku npm GitHubu s názvem 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 Webhooky
Poznámka:
Webhooky byly vydány v 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í pracovní postup na základě jakékoli události externího webhooku, která není podporována prostředky první třídy, 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 v kanálu prostředek webhooku a nasměrujete ho na příchozí připojení služby webhooku. Můžete také definovat další filtry pro prostředek webhooku na základě dat datové části JSON a přizpůsobit triggery pro každý kanál.
Pokaždé, když příchozí připojení služby webhooku obdrží událost webhooku, aktivuje se nové spuštění pro všechny kanály, 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 prostředek webhooku:
resources:
webhooks:
- webhook: WebHook
connection: IncomingWH
steps:
- script: echo ${{ parameters.WebHook.resource.message.title }}
Triggery 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 kanálu 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 - script: echo ${{ parameters.WebHook.resource.message }}
kanálu načítá celou zprávu JSON, která vygeneruje neplatný 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 plánovaných aktivačních událostí bere v úvahu pouze úspěšné dokončení spuštění CI nebo pokud verzi nevyberete ručně.
Pomocí nástroje pro výběr verze prostředku můžete při vytváření spuštění ručně zvolit jinou verzi. Výběr verze prostředku je podporovaný pro prostředky kanálu, sestavení, úložiště, kontejneru a balíčku.
U prostředků kanálu můžete zobrazit všechna dostupná spuštění napříč všemi větvemi, prohledávat je na základě čísla kanálu nebo větve a vybrat spuštění, které je úspěšné, neúspěšné nebo probíhající. Tato flexibilita zajišťuje, že kanál CD můžete spustit, pokud jste si jistí, že spuštění vytvořilo všechny potřebné artefakty. Nemusíte čekat na dokončení spuštění CI nebo ho 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ál prostředky a pak vyberte prostředek a v seznamu dostupných verzí vyberte konkrétní verzi.
Pro prostředky, ve kterých nemůžete načíst dostupné verze, jako jsou balíčky GitHubu, nabízí výběr verze textové pole, abyste mohli zadat verzi, kterou má spuštění vybrat.
Autorizace prostředků v kanálech YAML
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. Kanál YAML můžete autorizovat několika způsoby, jak používat prostředky.
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ích Projectu. 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 přidáte prostředek do souboru YAML a sestavení selže s chybou, jako
Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.
je , zobrazí se možnost autorizace prostředků v neúspěšném sestavení.Pokud jste členem role Uživatele pro prostředek, můžete tuto možnost vybrat a autorizovat prostředek v neúspěšném sestavení. Jakmile je prostředek autorizovaný, můžete spustit nové sestavení.
Ověřte správnost rolí zabezpečení fondu agentů pro váš projekt.
Kontroly schválení prostředků
Kontroly schválení a šablony můžete použít k ručnímu řízení, kdy se prostředek spustí. Při kontrole schválení požadované šablony můžete vyžadovat, aby se jakýkoli kanál využívající prostředek nebo prostředí rozšířil z konkrétní šablony 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 kanálu nebo úlohy nasazení.
Sledovatelnost kanálu
Azure Pipelines zobrazuje následující informace pro každé spuštění kanálu:
- Pokud prostředek aktivoval kanál, prostředek, který kanál aktivoval.
- Verze prostředku a spotřebované artefakty.
- Potvrzení přidružená k jednotlivým prostředkům.
- Pracovní položky přidružené ke každému zdroji
Sledovatelnost prostředí
Kdykoli se kanál nasadí do prostředí, zobrazí se seznam využívaných prostředků. Zobrazení zahrnuje prostředky spotřebované jako součást úloh nasazení a jejich přidružených potvrzení a pracovních položek.
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 vaše kanály CI využívají jiné kanály, 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 s triggerem prostředků
Triggery 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 kanálu nepodařilo spustit, vyberte položku nabídky Problémy s triggerem na stránce definice kanálu. Problémy s triggery jsou k dispozici pouze pro prostředky, které nejsou určené pro jiné prostředky.
Na stránce Problémy s triggerem popisují chybové zprávy a upozornění, 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?
pipelines
Použití prostředku je způsob, jak využívat artefakty z kanálu CI a také konfigurovat 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 kanálu, přidružené artefakty se automaticky stáhnou v úlohách nasazení.
Zástupce můžete použít download
ke stažení artefaktů v úlohách sestavení nebo k přepsání chování stahování v úlohách nasazení. Další informace najdete v definici steps.download.
Úloha Stažení artefaktů kanálu neposkytuje sledovatelnost ani triggery, 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 možná nebudete chtít přidat prostředek kanálu do šablony. Abyste se vyhnuli závislostem, můžete k předání všech informací o sestavení úkolu použít úlohu Stažení artefaktů kanálu.
Jak můžu aktivovat spuštění kanálu při aktualizaci image Docker Hubu?
Trigger prostředku kontejneru není k dispozici pro kanály Docker Hubu pro kanály YAML, takže je potřeba nastavit klasický kanál verze.
- Vytvořte nové připojení služby Docker Hub.
- Vytvořte klasický kanál verze a přidejte artefakt Docker Hubu. Nastavte připojení služby a vyberte obor názvů, úložiště, verzi a alias zdroje.
- Vyberte trigger a přepněte trigger průběžného nasazování na možnost Povolit. Každá nabízená oznámení Dockeru, která se vyskytuje ve vybraném úložišti, vytvoří verzi.
- Vytvořte novou fázi a úlohu. Přidejte dva úkoly, přihlášení Dockeru a Bash.
- Úloha Dockeru
login
má akci a přihlásí vás k Docker Hubu. - Úloha Bash se spustí
docker pull <hub-user>/<repo-name>[:<tag>]
.
- Úloha Dockeru
Jak můžu webhook ověřit a řešit potíže?
Vytvořte připojení služby.
Odkazujte na připojení ke službě a pojmenujte webhook v
webhooks
části.resources: webhooks: - webhook: MyWebhookTriggerAlias connection: MyServiceConnection
Spusťte kanál. 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ěď na stavový kód 200, váš webhook je připravený ke spotřebě kanálem.
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 kanálu 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 frontu.
- Po úspěšném spuštění tohoto kanálu proveďte
POST
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>
. Teď byste měli obdržet odpověď na stavový kód 200.
Související obsah
Váš názor
https://aka.ms/ContentUserFeedback.
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu:Odeslat a zobrazit názory pro