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, nebo selfse 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 versionbrancha 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, brancha 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 stageskanálu .
branches, tagsa 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 ve main větvi.
• Je označený oběma Verified a Signed
• 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 nonehodnotu 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, githubenterprisea 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
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 acrprostř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 resourceGrouprepository hodnoty registru kontejneru azureSubscriptionAzure. 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 části Výchozí větev kanálu.

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.

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

Jak můžu webhook ověřit a řešit potíže?

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

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

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

3. Spusťte kanál. 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ěď 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:

1. Na stránce kanálu 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 frontu.
6. 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 do 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.

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ření a cílení na prostředí
• Použití editoru kanálů YAML
• Referenční informace ke schématu YAML