Prostředky v YAML pipelinech

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Tento článek popisuje prostředky pro kanály YAML. Prostředek je cokoli, co kanál používá mimo tento kanál. Prostředky v kanálech YAML můžou být jiné kanály, buildy, kontejnery, balíčky, úložiště nebo webhooky.

Jakmile definujete prostředek, můžete ho využívat kdekoli ve vašem potrubí. Další informace a příklady najdete v tématu Definice prostředků.

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

Stav prostředku můžete použít k automatické aktivaci kanálů nastavením trigger vlastnosti v definici prostředku. resources.triggeringAlias Kanál a resources.triggeringCategory proměnné se pak nastaví na název a kategorii prostředku. Tyto proměnné jsou prázdné, pokud není proměnná nastavena Build.Reason na ResourceTrigger.

Prostředky umožňují úplnou sledovatelnost služeb, které kanál používá, včetně verze, artefaktů, přidružených potvrzení a pracovních položek. Pokud se přihlásíte k odběru aktivačních událostí vašich prostředků, můžete plně automatizovat pracovní postupy DevOps.

Poznámka:

Tento článek se věnuje především prostředkům v kanálech YAML. Informace o prostředcích v klasických kanálech najdete v tématu O prostředcích pro Azure Pipelines.

Autorizace prostředků

Prostředky musí být autorizované k použití 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í nastavení správy prostředku udělte přístupová oprávnění všem kanálům. Můžete například spravovat zabezpečené soubory a skupiny proměnných na stránceKnihovna> a fondy agentů a připojení služeb v nastaveních>Projectu. Tato autorizace je vhodná pro prostředky, které nepotřebujete omezit, například testovací prostředky.

• Ujistěte se, že máte alespoň roli uživatele v rolích zabezpečení fondu agentů pro váš projekt. Kanály YAML, které vytvoříte, mají automaticky oprávnění používat prostředky, ve kterých máte roli uživatele .

• Pokud do kanálu YAML přidáte definici prostředku, ale sestavení selže s chybou, například Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use, ujistěte se, že máte v prostředku aspoň roli uživatele . Pak můžete zvolit možnost autorizace prostředků v neúspěšném sestavení. Jakmile je zdroj autorizován, můžete spustit nové sestavení.

Kontroly schvalování zdrojů

K ručnímu řízení používání prostředků můžete použít kontroly schválení a šablony. Pomocí kontroly schválení požadované šablony můžete vyžadovat libovolný kanál, který používá určitý prostředek nebo prostředí, aby se rozšířil z konkrétní šablony YAML.

Nastavení požadovaného schválení šablony zvyšuje zabezpečení tím, že zajišťuje, aby se váš prostředek používal pouze za určitých podmínek. Další informace naleznete v tématu Použití šablon pro zabezpečení.

Ruční výběr verze prostředků

Azure Pipelines vyhodnocuje výchozí verze prostředků na základě jejich definic prostředků. U plánovaných spuštění nebo ručních spuštění, pokud ručně nevyberete spuštění, azure Pipelines považuje pouze úspěšně dokončená spuštění kontinuální integrace (CI) k vyhodnocení výchozích verzí prostředků.

Ruční výběr verze prostředků můžete použít k výběru různých verzí prostředků při ruční aktivaci kanálu průběžného nasazování YAML (CD). Výběr verze prostředku je podporovaný pro prostředky pipeline, sestavení, úložiště, kontejner a balíček.

U pipeline prostředků vám ruční výběr verze umožňuje zobrazit všechna dostupná spuštění ve všech větvích, prohledávat spuštění 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í.

Před spuštěním kanálu CD nemusíte čekat na dokončení spuštění CI nebo ho znovu spustit kvůli nesouvisejícímu selhání. Máte možnost zvolit jakékoli spuštění, které víte, že jste vytvořili potřebné artefakty.

Pokud chcete použít výběr verze prostředku, vyberte prostředky v podokně Spustit kanál , vyberte prostředek a v seznamu dostupných verzí vyberte konkrétní verzi. U prostředků, kde nemůžete načíst dostupné verze, jako jsou balíčky GitHubu, můžete do textového pole zadat požadovanou verzi.

Definice prostředků

Prostředky kanálu YAML můžou být:

• Další kanály
• Staví
• kontejnery
• Balíky
• Úložiště nebo
• Webhooky.

Následující části obsahují definice a příklady kategorií prostředků kanálu YAML. Úplné informace o schématu najdete v definici prostředků v referenčních informacích ke schématu YAML pro Azure Pipelines.

Prostředek Pipelines

Prostředky CI pipeline můžete použít jako triggery pro pracovní postupy CD. Můžete také odkazovat na pipeline prostředky z kanálu a stahovat artefakty nebo používat proměnné prostředků kanálu. Azure Pipelines mohou používat pouze prostředek pipelines.

V definici pipelines prostředku:

• pipeline je jedinečný název, který používáte k odkazování na prostředky kanálu.
• source je název kanálu, který vytvořil artefakty kanálu.

Úplné informace o schématu najdete v definici kanálu resources.pipelines.pipeline .

Ukázkové definice prostředků pipeline

Následující příklad definice prostředků využívá artefakty z kanálu ve stejném projektu Azure DevOps.

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 zadat kanál z jiného projektu, zahrňte název project do definice zdroje. Následující příklad také používá branch k vyřešení výchozí verze, když se kanál aktivuje ručně nebo podle plánu. Vstup větve nemůže obsahovat zástupné znaky.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

Vyhodnocení verze prostředku

Azure Pipelines vyhodnocuje výchozí verze prostředků na základě jejich definic prostředků. Výchozí verze artefaktů prostředků kanálu závisí na tom, jestli se kanál spouští ručně nebo podle plánu, nebo triggerů na základě výsledku spuštění prostředku.

V případě ručního nebo plánovaného spuštění kanálu definují hodnoty versionbranchtags a vlastnosti v pipeline definici prostředku verze artefaktů. Vstup branch nemůže obsahovat zástupné čáry a tags vlastnosti používají AND operátor.

U plánovaných spuštění nebo ručních spuštění, pokud nepoužíváte výběr verze, azure Pipelines při vyhodnocování výchozích verzí prostředků bere v úvahu, že se úspěšně dokončila pouze průběžná integrace (CI). U ručních spuštění můžete definované verze přepsat pomocí ručního výběru verzí.

Následující tabulka uvádí pipeline vlastnosti definice prostředků a verze artefaktů, které určují.

Zadaná vlastnost	Verze artefaktu
version	Sestavení se zadaným číslem spuštění
branch	Nejnovější build spuštěný v zadané větvi
tags	Nejnovější sestavení se všemi zadanými značkami
branch a tags	Nejnovější spuštění sestavení v zadané větvi, která má všechny zadané značky
version a branch	Sestavení se zadaným číslem spuštění a zadanou větví
Nic	Nejnovější sestavení napříč všemi větvemi

Následující pipeline definice prostředku používá branch vlastnosti a tags vlastnosti k vyhodnocení výchozí verze, pokud je kanál naplánován nebo aktivován ručně. Verze myCIAlias artefaktů je nejnovější spuštění sestavení ve main větvi, která obsahuje značky Production a PreProduction značky.

resources:
  pipelines:
  - pipeline: myCIAlias
    project: Fabrikam
    source: Fabrikam-CI
    branch: main
    tags:
    - Production
    - PreProduction

Triggery prostředků kanálu

U spuštění kanálu, která se aktivují na výsledku spuštění prostředku, trigger určují nastavení vlastností v definici prostředku výchozí verze artefaktů prostředků. Pokud chcete jako trigger použít pipeline prostředek ke spuštění aktuálního kanálu, musíte nastavit trigger vlastnost. Pokud nezahrnete trigger vlastnost, spuštění prostředků neaktivují aktuální spuštění kanálu.

Když se kanál aktivuje na trigger základě hodnoty v pipeline definici prostředku, hodnoty celkové definice versionbranchprostředku a tags vlastnosti se ignorují. Vlastnosti trigger určují verze 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, nebo selfse aktivuje ve stejné větvi a potvrzení, které vyvolá aktivační událost.
• pipeline Pokud prostředek pochází z jiného úložiště než aktuální kanál, aktivuje se ve výchozí větvi pipeline úložiště prostředků.

Následující tabulka popisuje, jak trigger vlastnosti ovlivňují chování triggeru.

Vlastnost triggeru	Chování spouštěče
true	K aktivaci dojde, když kanál prostředku úspěšně dokončí spuštění.
branches	K aktivaci dojde, když kanál prostředku úspěšně dokončí spuštění na jedné z include větví.
tags	K aktivaci dojde, když kanál prostředku úspěšně dokončí spuštění označené všemi zadanými značkami.
stages	K aktivaci dojde, když kanál prostředku úspěšně spustí zadaný stages.
branches, tags, a stages	K aktivaci dojde, když úspěšné spuštění kanálu prostředků splňuje všechny podmínky větve, značky a fáze.

Následující příklad ukazuje definici prostředku pipelines s jednoduchým trigger.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger: true

Následující příklad ukazuje zdroj pipeline trigger s podmínkami větví.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

Následující příklad používá stages filtry k vyhodnocení podmínek triggeru pro kanály CD. Aktivační událost stages používá AND operátor. Kanál CD se aktivuje po úspěšném dokončení všech uvedených fází.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Fabrikam-CI  
    trigger:    
      stages:
      - PreProduction
      - Production

Následující příklad používá tags filtry pro vyhodnocení výchozí verze a pro trigger. Značky trigger používají AND operátor. Sada tags v pipeline definicích prostředků se liší od značek nastavených na větvích v úložišti Git.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Fabrikam-CI
    tags: 
    - Production 
    trigger:
      tags:
      - Production
      - Signed

Následující potrubí se spustí, kdykoli se aktivuje potrubí prostředku SmartHotel-CI.

• Běží na jedné z releases větví nebo ve main větvi.
• Je označený oběma Verified a Signed.
• Dokončí jak fáze, Production tak PreProduction i fáze.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

Stažení artefaktů potrubí

Pomocí kroku v kanálu YAML můžete download stáhnout artefakty přidružené k aktuálnímu spuštění nebo jinému pipeline prostředku.

Artefakty se stahují automaticky jenom v úlohách nasazení. Všechny artefakty z aktuálního kanálu a všech jejích pipeline prostředků se automaticky stahují a jsou k dispozici na začátku každé úlohy nasazení. Toto chování můžete přepsat nastavením download na nonehodnotu nebo zadáním jiného pipeline identifikátoru prostředku.

V běžné úloze sestavení se artefakty automaticky nestahují. Explicitně použijte download v případě potřeby.

download V kroku volitelná artifact vlastnost určuje názvy artefaktů. Pokud není zadaný, všechny dostupné artefakty se stáhnutí.

Volitelná patterns vlastnost definuje vzory, které představují soubory ke stažení. Úplné informace o schématu najdete v definici steps.download .

- job: deploy_windows_x86_agent
  steps:
  - download: SmartHotel
    artifact: WebTier1
    patterns: '**/*.zip'

Artefakty z pipeline prostředku ke stažení do $(PIPELINE). WORKSPACE)/<pipeline-identifier>/<artifact-identifier> folder. Pro více informací se podívejte na Publikování a stahování artefaktů pipeline. Alternativní způsob stahování artefaktů kanálu najdete v tématu Stažení artefaktů.

Proměnné zdrojů kanálu

Metadata prostředku kanálu jsou k dispozici pro všechny úlohy v každém spuštění 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 Definování proměnných a metadat prostředků kanálu jako předdefinovaných 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)

Prostředek Sestavení

Pokud máte systém sestavení CI, který vytváří artefakty, můžete artefakty využívat s builds prostředky.

Kategorie builds je rozšiřitelná. Prostředek build může být z libovolného externího systému CI, jako je Jenkins, TeamCity nebo CircleCI. Můžete použít builds k zápisu rozšíření pro využívání artefaktů ze služby sestavení nebo k zavedení nového typu služby.

build V definici version se ve výchozím nastavení nastaví nejnovější úspěšné sestavení. V případě potřeby musíte explicitně nastavit trigger . Úplné informace o schématu najdete v definici resources.builds.build .

V následujícím příkladu je Jenkins typem prostředku.

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 automaticky nestahují do úloh nebo úloh deploy-jobs. 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.

Úloha downloadBuild 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 ke stažení 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ý, všechny artefakty přidružené ke stažení prostředku.

Volitelná patterns vlastnost určuje cestu minimatch nebo seznam cest minimatch ke stažení. Pokud je prázdný, celý artefakt se stáhne. Následující příklad 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 .

Prostředek úložišť

Pomocí klíčového repository slova dejte systému vědět o externích úložištích, pokud:

• Váš kanál obsahuje šablony v jiném úložišti.
• Chcete použít rezervaci s více úložišti s úložištěm, které vyžaduje připojení ke službě.

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 gittypy , githubgithubenterprise, a bitbucket úložiště.

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

Následující tabulka popisuje repository typy prostředků:

Typ	Hodnota názvu	Příklad
git	Jiné úložiště ve stejném projektu nebo stejné organizaci.	Stejný projekt: name: otherRepo Jiný projekt ve stejné organizaci: name: otherProject/otherRepo.
github	Úplný název úložiště GitHub, včetně uživatele nebo organizace.	name: myOrganization/otherRepo
githubenterprise	Úplný název úložiště GitHub Enterprise, včetně uživatele nebo organizace.	name: myEnterpriseOrg/otherRepo
bitbucket	Úplný název úložiště Bitbucket Cloud včetně uživatele nebo organizace.	name: MyBitbucketOrg/otherRepo

Proměnné prostředků úložiště

Metadata prostředku úložiště jsou k dispozici pro všechny úlohy v každém spuštění jako proměnné modulu runtime. Jedná se <alias> o repository identifikátor z repository vaší definice prostředku.

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 má alias common, takže přistupujete k proměnným prostředků úložiště 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. Klíčové slovo můžete použít checkout k načtení úložiště definovaného repository v prostředku. Další informace najdete v tématu Prohlédněte si více úložišť ve svém kanálu. Úplné informace o schématu najdete v definici steps.checkout .

Prostředek kontejnerů

Prostředky můžete použít containers ke zpracování imagí kontejnerů v kanálech CI/CD. Prostředek container může být veřejný nebo privátní registr Dockeru nebo instance služby Azure Container Registry.

Image obecného prostředku kontejneru můžete využívat jako součást úloh nebo ji použít v úlohách kontejneru. Pokud váš kanál vyžaduje podporu jedné nebo více služeb, musíte také 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, můžete definovat obecný prostředek kontejneru bez použití klíčového type slova. 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 značky imagí 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 ve svých úlohách a povolit automatické triggery 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 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 se provádí 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 tématu 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 typ prostředku kontejneru acr .

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)

Prostředek Packages

Balíčky NuGet a npm GitHubu můžete využívat jako zdroje v pipelinách YAML. Chcete-li 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 balíček <repository>\<name> ve name vlastnosti 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 .

Balíčky se ve výchozím nastavení 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

steps:
- getPackage: contoso

Prostředek Webhooky

Poznámka:

Webhooky vydané v Azure DevOps Serveru 2020.1

K využívání artefaktů a automatizaci triggerů můžete použít kanál Azure Pipelines, kontejner, sestavení a zabalení prostředků, ale nemůžete je použít k základu nasazení na externích událostech nebo službách. Webhooky automatizují pracovní postup na základě externích událostí webhooku, které prvotřídní prostředky Azure Pipelines nepodporují. Můžete se přihlásit k odběru externích událostí prostřednictvím webhooků a pomocí událostí aktivovat vaše kanály.

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. U místních služeb, ve kterých Azure DevOps nemá přehled o procesu, můžete nakonfigurovat webhooky ve službě tak, aby aktivovaly vaše kanály automaticky.

Pokud se chcete přihlásit k odběru události webhooku, definujete webhook v kanálu prostředek a zadáte příchozí připojení služby webhooku. Úplné informace o schématu najdete v definici resources.webhooks.webhook .

Data datové části JSON můžete využívat jako proměnné v úlohách pomocí formátu ${{ parameters.<WebhookAlias>.<JSONPath>}}. Následující příklad definuje a potom volá prostředek webhooku:

resources:
  webhooks:
    - webhook: myWebhookResource
      connection: myWebHookConnection

steps:  
- script: echo ${{ parameters.myWebHookResource.resource.message.title }}

Filtry prostředku webhooku můžete definovat 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.

Následující příklad používá filtry webhooků.

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}}

Konfigurace triggeru Webhooku

Pokud chcete nakonfigurovat trigger webhooku, nastavíte webhook v externí službě a poskytnete následující informace:

• Adresa URL požadavku: https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview
• Tajný kód (volitelné): Pokud potřebujete datovou část JSON zabezpečit, zadejte hodnotu tajného kódu.

Vpřipojeních> Service pro > projektu Azure DevOps vytvoříte nové příchozí připojení služby webhooku. Můžete například definovat následující informace pro typ připojení služby GitHub:

• Název webhooku: Název připojení webhooku, který jste vytvořili v externí službě.
• Tajný kód (volitelné): Hodnota hash datové části HMAC-SHA1 k 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 (volitelné): Hlavička HTTP v požadavku, která obsahuje datovou část HMAC-SHA1 hodnotu hash 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. Jakýkoli kanál aktivovaný prostřednictvím tohoto webhooku se nespustí, protože vygenerovaný YAML je neplatný.

Sledovatelnost

Azure Pipelines poskytuje úplnou sledovatelnost všech prostředků spotřebovaných na úrovni pipelines nebo úrovni úlohy nasazení. Azure Pipelines zobrazuje následující informace pro každé spuštění kanálu, které používá prostředky:

• Pokud prostředek aktivoval kanál, prostředek, který kanál aktivoval.
• Verze prostředků a artefakty spotřebované.
• Změny přidružené k jednotlivým prostředkům.
• Pracovní položky přidružené ke každému zdroji

Přidružené informace o kanálu CD pro kanály CI

Pokud chcete poskytovat kompletní sledovatelnost, můžete sledovat, které kanály CD spotřebovávají konkrétní kanál CI prostřednictvím pipelines prostředku. Pokud vaše kanály CI spotřebovaly 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.

Sledovatelnost prostředí

Po nasazení kanálu do prostředí můžete zobrazit seznam prostředků, které spotřeboval, a jejich přidružené potvrzení a pracovní položky.

časté otázky

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

1. Vytvořte nové připojení služby Docker Hub.
2. 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.
3. 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í.
4. 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>].

Jak mohu ověřit a odstraňovat problémy u svého webhooku?

1. Vytvořte připojení služby.

2. Odkazujte na připojení ke službě a pojmenujte webhook v části webhooks.

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

3. Spusťte potrubí. Webhook se vytvoří v Azure jako distribuovaný úkol pro vaši organizaci.

4. POST Proveďte volání rozhraní API s platným kódem JSON v textu do https://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:

1. Na stránce potrubí vyberte Upravit.
2. V nabídce Další akce vyberte Aktivační události.
3. Vyberte kartu YAML a pak vyberte Získat zdroje.
4. V části Výchozí větev pro ruční a naplánované sestavení aktualizujte větev funkcí.
5. Vyberte Uložit a zařadit do fronty.
6. Po úspěšném spuštění tohoto pipeline proveďte POST volání rozhraní API s platným JSON obsahem na https://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.

Proč můj prostředek nefungoval?

Spouštěče prostředků se nedají spustit, protože:

• Zdroj poskytnutého připojení služby je neplatný.
• Trigger není nakonfigurovaný nebo se v triggeru zobrazují chyby syntaxe.
• 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í. Problémy s triggerem nejsou dostupné pro prostředky úložiště.

Na stránce Problémy s triggerem chybové zprávy a upozornění popisují, proč se trigger nezdařil.

Související obsah

• Informace o prostředcích pro Azure Pipelines
• Definování proměnných
• Přidání a použití skupin proměnných
• Vytvořte a zacílete na prostředí
• Použití editoru kanálů YAML
• Referenční informace ke schématu YAML