Prostředky v YAML pipelinech

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Tento článek popisuje prostředky pro kanály YAML. Prostředek je cokoli, co používá pipeline a existuje mimo ni. Jakmile definujete prostředek, můžete ho využívat kdekoli ve vašem potrubí.

Prostředky poskytují úplnou sledovatelnost služeb, které vaše pipeline používá, včetně verze, artefaktů, přidružených commitů a pracovních položek. Pracovní postupy DevOps můžete plně automatizovat tím, že se přihlásíte k odběru spouštěcích událostí ve vašich prostředcích.

Schéma prostředků

Prostředky v YAML představují zdroje kanálů, buildů, úložišť, kontejnerů, balíčků a webhooků. Pro úplné informace o schématu se podívejte na definici prostředků v referenčních informacích ke schématu YAML pro Azure Pipelines.

Když prostředek aktivuje pipeline, nastaví se následující proměnné:

resources.triggeringAlias
resources.triggeringCategory

Aby se tyto hodnoty nastavily, musí být Build.Reason proměnnáResourceTrigger. Hodnoty jsou prázdné, pokud prostředek neaktivoval potrubí.

Definice zdroje Pipelines

Pokud máte kanál, který vytváří artefakty, můžete artefakty využívat definováním pipelines prostředku. Azure Pipelines mohou používat pouze prostředek pipelines. Triggery pro pracovní postupy průběžného nasazování (CD) můžete nastavit u kanálového prostředku.

V definici prostředku je pipeline jedinečná hodnota, kterou můžete použít k odkazování na prostředek kanálu později v kanálu. Jedná se source o název kanálu, který vytvořil artefakt kanálu. Úplné informace o schématu najdete v definici resources.pipelines.pipeline.

Použijete název definovaný pomocí pipeline k odkazování na prostředek pipeline z jiných částí pipeline, například při použití proměnných prostředků pipeline nebo stahování artefaktů. Alternativní způsob stahování artefaktů kanálu najdete v tématu Stažení artefaktů.

Důležité

Při definování spouštěče zdroje pipeline:

• pipeline Pokud je prostředek ze stejného úložiště jako aktuální kanál, nebo self, spuštění sleduje stejnou větev a potvrzení, na kterých byla událost vyvolána.
• Pokud prostředek kanálu pochází z jiného úložiště, aktuální kanál se aktivuje ve výchozí větvi pipeline úložiště prostředků.

Ukázkové definice prostředků pipeline

Následující příklad využívá artefakty z pipeline ve stejném projektu.

resources:
  pipelines:
  - pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
    source: SmartHotel-CI # name of the pipeline that produces the artifacts

Pokud chcete získat přístup k pipeline z jiného projektu, zahrnete název projektu a název zdroje. Následující příklad používá branch k vyřešení výchozí verze při ručním nebo naplánovaném spuštění kanálu. Vstup větve nemůže obsahovat zástupné znaky.

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

Následující příklad ukazuje prostředek kanálu s jednoduchým triggerem.

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

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

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

Následující příklad používá stages filtry k vyhodnocení podmínek spuštění pro CD pipelines. Fáze používají AND operátor. Po úspěšném dokončení všech zadaných etap se aktivuje CD pipeline.

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

Následující příklad používá tags filtry pro vyhodnocení výchozí verze a pro triggery. Značky používají AND operátor.

Na kanálu kontinuální integrace (CI) nebo CD jsou nastaveny tags. Tyto značky se liší od značek nastavených ve větvích v úložišti Git.

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

Vyhodnocení verze artefaktu potrubí

Verze artefaktu potrubí prostředku závisí na tom, jak se potrubí spustí.

Ruční nebo naplánovaná aktivační událost

Pokud je spuštění kanálu ručně aktivováno nebo naplánováno, hodnoty version, branch a tags vlastnosti definují verzi artefaktu. Vstup branch nemůže obsahovat zástupné znaky. Vlastnosti tags používají AND operátor.

Zadané vlastnosti	Verze artefaktu
version	Artefakty ze sestavení, které mají zadané číslo spuštění
branch	Artefakty z nejnovějšího sestavení provedeného v zadané větvi
tags seznam	Artefakty z nejnovější verze, které mají všechny zadané značky
branch a tags seznam	Artefakty z nejnovějšího sestavení provedeného v zadané větvi, která má všechny zadané značky
version a branch	Artefakty z buildu se specifikovaným číslem spuštění a specifikovanou větví.
Nic	Artefakty z nejnovějšího buildu ve všech větvích

Následující pipeline definice zdroje používá vlastnosti branch a tags k vyhodnocení výchozí verze při ručním nebo plánovaném spuštění pipeline. Když ručně spustíte potrubí, verze artefaktů potrubí je nejnovější build provedený na větvi MyCIAlias, která má značky main a Production.

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

Aktivace dokončení potrubí zdrojů

Když se potrubí aktivuje, protože jeden z jeho potrubí prostředků je dokončen, verze artefaktů je verze spouštěcího potrubí. Hodnoty objektu version, brancha tags vlastnosti jsou ignorovány.

Zadané spouštěče	Výsledek
branches	Nové spuštění potrubí se aktivuje vždy, když potrubí prostředků úspěšně dokončí spuštění na jedné z include větví.
tags	Nové spuštění kanálu se aktivuje pokaždé, když zdrojový kanál úspěšně dokončí spuštění označené všemi specifikovanými značkami.
stages	Nové spuštění kanálu se spustí při každém úspěšném provedení zadaného kanálu prostředku stages.
branches, tags, a stages	Nové spuštění kanálu se spustí pokaždé, když spuštění kanálu zdrojů splňuje všechny podmínky větve, značek a fází.
trigger: true	Nové spuštění pipeline se aktivuje pokaždé, když se pipeline zdroje úspěšně dokončí.
Nic	Po úspěšném dokončení spuštění zdrojového kanálu se nespustí žádné nové spuštění kanálu.

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

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

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

Stažení artefaktů potrubí

Krok download stáhne artefakty přidružené k aktuálnímu běhu nebo k jinému kanálovému prostředku.

Všechny artefakty z aktuálního potrubí a všechny jeho pipeline prostředky se automaticky stáhnou a zpřístupní na začátku každé úlohy nasazení. Toto chování můžete přepsat nastavením download na none nebo zadáním jiného identifikátoru prostředku pipeline.

Artefakty běžných úloh se nestáhnou automaticky. Explicitně použijte download v případě potřeby.

Artefakty z pipeline prostředku se stáhnou do $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> složky. Pro více informací se podívejte na Publikování a stahování artefaktů pipeline.

Volitelná artifact vlastnost určuje názvy artefaktů. Pokud není zadaný, stáhnou se všechny dostupné artefakty. Volitelná patterns vlastnost definuje vzory, které představují soubory, které se mají zahrnout. Úplné informace o schématu najdete v definici steps.download.

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

Proměnné zdrojů kanálu

V každém spuštění jsou metadata zdroje pipeline k dispozici pro všechny úlohy jako předdefinované proměnné. Tyto proměnné jsou k dispozici pro váš kanál pouze za běhu, a proto je nelze použít ve výrazech šablony, které se vyhodnocují v době kompilace kanálu.

Další informace najdete v tématu Metadata prostředků kanálu jako předdefinované proměnné. Další informace o syntaxi proměnných najdete v tématu Definování proměnných.

Příklad níže vrátí předdefinované hodnoty proměnných pro zdroj kanálu myresourcevars.

resources:
  pipelines:
  - pipeline: myresourcevars
    source: mypipeline
    trigger: true 

steps:
- script: |
    echo $(resources.pipeline.myresourcevars.pipelineID)
    echo $(resources.pipeline.myresourcevars.runName)
    echo $(resources.pipeline.myresourcevars.runID)
    echo $(resources.pipeline.myresourcevars.runURI)
    echo $(resources.pipeline.myresourcevars.sourceBranch)
    echo $(resources.pipeline.myresourcevars.sourceCommit)
    echo $(resources.pipeline.myresourcevars.sourceProvider)
    echo $(resources.pipeline.myresourcevars.requestedFor)
    echo $(resources.pipeline.myresourcevars.requestedForID)

Vytváření definice prostředku

Pokud máte externí systém sestavení CI, který vytváří artefakty, můžete artefakty zpracovat pomocí prostředků builds. Prostředek build může být z libovolného externího systému CI, jako je Jenkins, TeamCity nebo CircleCI.

Kategorie builds je rozšiřitelná. Můžete napsat rozšíření pro spotřebovávání artefaktů ze služby sestavení a zároveň zavést nový typ služby jako součást builds.

build V definici version se ve výchozím nastavení nastaví nejnovější úspěšné sestavení. trigger není ve výchozím nastavení povoleno a musí být explicitně nastaveno. Úplné informace o schématu najdete v definici resources.builds.build.

V následujícím příkladu je Jenkins zdrojem type.

resources:
  builds:
  - build: Spaceworkz
    type: Jenkins
    connection: MyJenkinsServer 
    source: SpaceworkzProj   # name of the Jenkins source project
    trigger: true

Důležité

Spouštěče se podporují jenom pro hostovaný Jenkins, kde má Azure DevOps přímý přístup k serveru Jenkins.

Úloha downloadBuild

Artefakty build prostředků se ve vašich úlohách nebo úlohách deploy-jobs nestáhnou automaticky. Pokud chcete využívat artefakty z build prostředku jako součást svých úloh, musíte explicitně přidat úlohu downloadBuild. Můžete přizpůsobit chování stahování pro každé nasazení nebo úlohu.

Tato úloha se automaticky přeloží na odpovídající úlohu stahování pro typ build prostředku, který modul runtime definuje. Artefakty z build prostředku se stáhnou do $(PIPELINE.WORKSPACE)/<build-identifier>/ složky.

downloadBuild V definici zadáte prostředek, ze kterém se mají stahovat artefakty. Volitelná artifact vlastnost určuje artefakty ke stažení. Pokud není zadáno, stáhnou se všechny artefakty přidružené k prostředku.

Volitelná patterns vlastnost určuje cestu minimatch nebo seznam cest minimatch ke stažení. Pokud je prázdný, stáhne se celý artefakt. Například následující fragment kódu stáhne pouze soubory *.zip .

- job: deploy_windows_x86_agent
  steps:
  - downloadBuild: Spaceworkz
    patterns: '**/*.zip'

Úplné informace o schématu najdete v definici steps.downloadBuild.

Definice prostředku úložiště

Klíčové repository slovo umožňuje zadat externí úložiště. Tento prostředek můžete použít, pokud váš kanál sestavení obsahuje šablony v jiném úložišti nebo chcete použít multi-repo checkout s úložištěm, které vyžaduje připojení služby. Musíte dát systému vědět o těchto úložištích.

Příklad:

resources:
  repositories:
  - repository: common
    type: github
    name: Contoso/CommonTools
    endpoint: MyContosoServiceConnection

Úplné informace o schématu najdete v definici resources.repositories.repository.

Typy prostředků úložiště

Azure Pipelines podporuje následující hodnoty pro typ úložiště: git, github, 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ě

Při každém spuštění jsou následující metadata zdroje úložiště k dispozici všem úlohám ve formě proměnných za běhu. <Alias> je identifikátor, který dáte prostředku úložiště.

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
resources.repositories.<Alias>.version

Následující příklad obsahuje prostředek úložiště s aliasem common, takže proměnné prostředků úložiště jsou přístupné pomocí resources.repositories.common.*.

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]
  version: $[ resources.repositories.common.version ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"
    echo "version = $(version)"

Klíčové slovo pro přístup k repozitářům

Repozitáře z repository prostředku nejsou ve vašich úlohách automaticky synchronizovány. Použijte klíčové slovo checkout k načtení úložiště definovaného jako součást zdroje repository. Úplné informace o schématu najdete v definici steps.checkout.

Další informace najdete v tématu Prohlédněte si více úložišť ve svém kanálu.

Definice prostředků kontejnerů

Pokud potřebujete využívat image kontejnerů jako součást CI/CD pipeline, můžete použít containers prostředky. Prostředek container může být veřejný nebo privátní registr Dockeru nebo instance služby Azure Container Registry.

Jako součást úlohy můžete použít obecný obraz prostředku kontejneru nebo tento prostředek využít pro kontejnerové úlohy. Pokud váš kanál vyžaduje podporu jedné nebo více služeb, musíte vytvořit a připojit se ke kontejnerům služeb. Můžete použít svazky ke sdílení dat mezi službami.

Pokud potřebujete využívat obrazy z registru Dockeru jako součást vývojové linky, můžete definovat obecný prostředek kontejneru. Není vyžadováno žádné type klíčové slovo. Příklad:

resources:         
  containers:
  - container: smartHotel 
    endpoint: myDockerRegistry
    image: smartHotelApp 

Úplné informace o schématu najdete v definici resources.containers.container.

Poznámka:

Syntaxe enabled: 'true' pro povolení triggerů kontejneru pro všechny značky obrazů se liší od syntaxe pro jiné triggery prostředků. Nezapomeňte použít správnou syntaxi pro konkrétní prostředky.

Typ prostředku Azure Container Registry

Pokud chcete spotřebovávat image služby Azure Container Registry, můžete použít typ prostředku první třídy acr kontejneru. Tento typ prostředku můžete použít jako součást svých pracovních úkolů a povolit automatické spouštění pipeline.

K používání kanálu s automatickými spouštěči potřebujete oprávnění přispěvatele nebo vlastníka služby Azure Container Registry. Další informace najdete v tématu Role a oprávnění služby Azure Container Registry.

Pokud chcete použít typ prostředku acr, musíte specifikovat hodnoty azureSubscription, resourceGroup, a repository pro váš Azure registr kontejnerů. Příklad:

resources:         
  containers:
  - container: petStore      
    type: acr  
    azureSubscription: ContosoConnection
    resourceGroup: ContosoGroup
    registry: petStoreRegistry
    repository: myPets
    trigger: 
      tags:
        include: 
        - production* 

Poznámka:

Vyhodnocení triggeru probíhá pouze ve výchozí větvi. Nezapomeňte nastavit správnou výchozí větev nebo sloučit soubor YAML do aktuální výchozí větve. Další informace o tom, jak změnit výchozí větev kanálu, najdete v části Výchozí větev kanálu.

Proměnné prostředků kontejneru

Po definování kontejneru jako prostředku se metadata kontejnerového obrazu předají kanálu jako proměnné. Informace, jako jsou image, registr a podrobnosti o připojení, jsou přístupné napříč všemi úlohami použitými v úlohách nasazení kontejneru.

Proměnné prostředků kontejneru fungují s Dockerem a službou Azure Container Registry. Nemůžete použít proměnné prostředků kontejneru pro lokální image kontejnery. Proměnná location se vztahuje pouze na acr typ prostředků kontejneru.

Následující příklad obsahuje připojení služby Azure Resource Manager s názvem arm-connection. Další informace najdete v tématu Registry kontejnerů, úložiště a image Azure.

resources:
  containers:
  - container: mycontainer
    type: ACR
    azureSubscription: arm-connection
    resourceGroup: rg-storage-eastus
    registry: mycontainerregistry
    repository: hello-world
    trigger:
      tags:
      - latest

steps:
- script: echo |
    echo $(resources.container.mycontainer.type)
    echo $(resources.container.mycontainer.registry)
    echo $(resources.container.mycontainer.repository)
    echo $(resources.container.mycontainer.tag)
    echo $(resources.container.mycontainer.digest)
    echo $(resources.container.mycontainer.URI)
    echo $(resources.container.mycontainer.location)

Definice zdroje balíčků

Balíčky NuGet a npm GitHubu můžete využívat jako zdroje v pipelinách YAML. Pokud chcete povolit automatické triggery kanálu při vydání nové verze balíčku, nastavte vlastnost trigger na true.

Při definování package prostředků zadejte do vlastnosti úložiště<>/název<> balíčku namea nastavte balíček type jako NuGet nebo npm. Pokud chcete používat balíčky GitHub, použijte ověřování na základě PAT a vytvořte připojení ke službě GitHub, které používá PAT.

Úplné informace o schématu naleznete v definici resources.packages.package.

Ve výchozím nastavení se balíčky automaticky nestáhnou do úloh. Ke stažení použijte getPackage.

Následující příklad obsahuje GitHub service connection pojmenované pat-contoso a GitHub npm balíček pojmenovaný contoso. Další informace najdete v balíčcích GitHubu.

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

pool:
  vmImage: 'ubuntu-latest'

steps:
- getPackage: contoso

Definice prostředku Webhook

Poznámka:

Webhooky byly vydány ve Azure DevOps Serveru 2020.1.

Artefakty můžete využívat a povolit automatizované triggery s prostředky kanálu, kontejneru, sestavení a balíčku. Tyto prostředky ale nemůžete použít k automatizaci nasazení na základě externích událostí nebo služeb.

Prostředek webhooks v kanálech YAML umožňuje integrovat vaše kanály s externími službami, jako jsou GitHub, GitHub Enterprise, Nexus a Artifactory, a automatizovat pracovní postupy. Můžete se přihlásit k odběru jakýchkoli externích událostí prostřednictvím webhooků a pomocí událostí aktivovat vaše kanály.

Webhooky automatizují váš pracovní postup na základě jakékoli externí události webhooku, která není podporována prvotřídními zdroji, jako jsou kanály, buildy, kontejnery nebo balíčky. U místních služeb, kde Azure DevOps nemá přehled o procesu, můžete také nakonfigurovat webhooky ve službě a aktivovat kanály automaticky.

Pokud se chcete přihlásit k odběru události webhooku, definujete prostředek webhooku ve vašem pipeline a nasměrujete ho na příchozí připojení ke službě webhooku. Můžete také definovat další filtry pro prostředek webhooku na základě dat JSON, abyste přizpůsobili spouštěče pro každé potrubí.

Pokaždé, když příchozí připojení služby webhooku obdrží událost webhooku, spustí se nový běh pro všechny pipelines, které se přihlásily k odběru události webhooku. Data datové části JSON můžete ve svých úlohách využívat jako proměnné pomocí formátu ${{ parameters.<WebhookAlias>.<JSONPath>}}.

Úplné informace o schématu najdete v definici resources.webhooks.webhook.

Následující příklad definuje zdroj webhooku:

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

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

Spouštěče webhooku

Pokud chcete nakonfigurovat triggery webhooku, nejprve ve své externí službě nastavíte webhook s následujícími informacemi:

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

Dále vytvoříte nové příchozí připojení služby webhooku. Pro tento typ připojení služby definujete následující informace:

• Název webhooku: Stejný jako webhook vytvořený ve vaší externí službě.
• Tajný kód (volitelné): Slouží k ověření hodnoty hash HMAC-SHA1 datové části pro ověření příchozího požadavku. Pokud jste při vytváření webhooku použili tajný kód, musíte zadat stejný tajný kód.
• Hlavička HTTP: Hlavička HTTP v požadavku, která obsahuje hodnotu hash HMAC-SHA1 datové části pro ověření požadavku. Například hlavička požadavku GitHubu je X-Hub-Signature.

K aktivaci potrubí pomocí webhooku provedete POST požadavek na https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview. Tento koncový bod je veřejně dostupný a nepotřebuje žádnou autorizaci. Požadavek by měl mít text podobný následujícímu příkladu:

{
    "resource": {
        "message": {
            "title": "Hello, world!",
            "subtitle": "I'm using WebHooks!"
        }
    }
}

Poznámka:

Přístup k datům z textu požadavku webhooku může vést k nesprávnému YAML. Například krok kanálu - script: echo ${{ parameters.WebHook.resource.message }} načítá celou zprávu JSON, což vede ke generování neplatného YAML. Žádný kanál aktivovaný prostřednictvím tohoto webhooku se nespustí, protože vygenerovaný YAML začal být neplatný.

Následující fragment kódu ukazuje další příklad, který používá filtry webhooku.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          
      connection: MyWebhookConnection    
      filters:
        - path: repositoryName      
          value: maven-releases     
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

Ruční výběr verzí pro prostředky

Když ručně aktivujete kanál CD YAML, Azure Pipelines automaticky vyhodnotí výchozí verze pro prostředky definované v kanálu na základě zadaných vstupů. Azure Pipelines ale při vyhodnocování výchozí verze pro plánované aktivační události bere v úvahu pouze úspěšná spuštění CI, nebo pokud verzi nevyberete ručně.

Pomocí nástroje volby verze prostředku můžete při zahájení běhu ručně zvolit jinou verzi. Výběr verze prostředku je podporovaný pro prostředky pipeline, sestavení, úložiště, kontejner a balíček.

U zdrojů potrubí můžete zobrazit všechna dostupná spuštění ve všech větvích, vyhledávat je podle čísla potrubí nebo větve a vybrat spuštění, které je úspěšné, neúspěšné nebo probíhající. Tato flexibilita zajišťuje, že můžete spustit CD kanál, pokud jste si jistí, že běh vytvořil všechny potřebné artefakty. Nemusíte čekat na dokončení běhu CI nebo jej znovu spustit kvůli selhání nesouvisející fáze.

Pokud chcete použít výběr verze prostředku, vyberte v podokně Spustit kanálProstředky, pak vyberte prostředek a v seznamu dostupných verzí vyberte konkrétní verzi.

Pro prostředky, kde nemůžete načíst dostupné verze, jako jsou balíčky na GitHub, výběr verze obsahuje textové pole, abyste mohli zadat verzi, kterou má použít při spuštění.

Autorizace prostředků v YAML pipelinech

Prostředky musí být autorizované, aby je bylo možné použít v kanálech. Vlastníci prostředků řídí uživatele a kanály, které mají přístup ke svým prostředkům. Existuje několik způsobů, jak autorizovat kanál YAML k použití prostředků.

• Pomocí prostředí pro správu prostředků můžete autorizovat všechny kanály pro přístup k prostředku. Například skupiny proměnných a zabezpečené soubory se spravují na stránce Knihovna v části Kanály, a fondy agentů a připojení služeb se spravují v Nastavení projektu. Tato autorizace je praktická, pokud nepotřebujete omezit přístup k prostředkům, jako jsou testovací prostředky.

• Při vytváření kanálu jsou všechny prostředky odkazované v souboru YAML automaticky autorizované k použití kanálem, pokud pro tyto prostředky máte roli Uživatel .

• Pokud do souboru YAML přidáte prostředek a sestavení selže s chybou, jako je Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use., zobrazí se možnost autorizovat prostředky u neúspěšného sestavení.

  Pokud máte roli Uživatele pro prostředek, můžete tuto možnost vybrat a autorizovat prostředek pro neúspěšné sestavení. Jakmile je zdroj autorizován, můžete spustit nové sestavení.

• Zkontrolujte, zda jsou role zabezpečení ve fondu agentů pro váš projekt správné.

Kontroly schvalování zdrojů

Kontroly schválení a šablony můžete použít k tomu, abyste ručně řídili, kdy se prostředek spustí. Pomocí kontroly schválení požadované šablony můžete vyžadovat, aby jakákoli pipelina využívající prostředek nebo prostředí využívala konkrétní šablonu YAML.

Nastavení požadovaného schválení šablony zajistí, že se váš prostředek použije jenom za určitých podmínek, a zlepší zabezpečení. Další informace o vylepšení zabezpečení kanálů pomocí šablon najdete v tématu Použití šablon pro zabezpečení.

Sledovatelnost

Azure Pipelines poskytuje úplnou sledovatelnost všech prostředků spotřebovaných na úrovni pipelines nebo úrovni úlohy nasazení.

Sledovatelnost kanálu

Azure Pipelines zobrazuje následující informace pro každý běh potrubí:

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

Sledovatelnost prostředí

Pokaždé, když se pipeline nasadí do prostředí, zobrazí se seznam využívaných zdrojů. Zobrazení zahrnuje prostředky spotřebované jako součást úloh nasazení a s nimi spojená potvrzení a pracovní položky.

Informace o přidružených kanálech CD v kanálech CI

Pokud chcete zajistit kompletní sledovatelnost, můžete sledovat, které kanály CD využívají konkrétní kanál CI prostřednictvím pipelines prostředku. Pokud jiné kanály využívají váš CI kanál, zobrazí se v zobrazení Spustit karta Přidružené kanály. V zobrazení se zobrazí všechna spuštění kanálu YAML CD, která kanál CI spotřebovala, a artefakty z něj.

Problémy se spouštěním prostředků

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

• Zdroj poskytnutého připojení služby je neplatný, v triggeru jsou chyby syntaxe nebo trigger není nakonfigurovaný.
• Podmínky triggeru se neshodují.

Pokud chcete zjistit, proč se triggery v potrubí nepodařilo spustit, vyberte položku nabídky Problémy s triggery na stránce definice potrubí. Problematika triggerů je k dispozici pouze pro prostředky mimo repozitář.

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

Často kladené dotazy

Kdy mám použít prostředky kanálů, zástupce pro stažení nebo úlohu Stáhnout artefakty kanálu?

Použití prostředku pipelines je způsob, jak využívat artefakty z CI pipeline a také nastavit automatizované triggery. Prostředek poskytuje úplný přehled o procesu zobrazením spotřebované verze, artefaktů, potvrzení a pracovních položek. Když definujete prostředek pipeline, přidružené artefakty se automaticky stáhnou v úlohách nasazení.

Zkratku download můžete použít ke stažení artefaktů v úlohách sestavení nebo k úpravě způsobu stahování v úlohách nasazení. Další informace najdete v definici steps.download.

Úloha stažení artefaktů kanálu neposkytuje sledovatelnost ani aktivátory, ale někdy má smysl tuto úlohu použít přímo. Můžete mít například úlohu skriptu uloženou v jiné šabloně, která vyžaduje stažení artefaktů z sestavení. Nebo třeba nebudete chtít přidat prostředek kanálu do šablony. Abyste se vyhnuli závislostem, můžete použít úlohu Stažení artefaktů kanálu k předání všech informací o sestavení na úkol.

Jak mohu spustit pipeline, když se aktualizuje image na Docker Hubu?

Trigger kontejnerového prostředku není k dispozici pro Docker Hub na YAML potrubích, takže je potřeba nastavit klasické potrubí vydání.

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.

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