Ressourcen in YAML-Pipelines

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

In diesem Artikel werden Ressourcen für YAML-Pipelines erläutert. Eine Ressource ist alles, was von einer Pipeline verwendet wird, die außerhalb der Pipeline vorhanden ist. Nachdem Sie eine Ressource definiert haben, können Sie sie überall in Ihrer Pipeline nutzen.

Ressourcen bieten vollständige Rückverfolgbarkeit für die Dienste, die Ihre Pipeline verwendet, einschließlich Der Version, Artefakte, zugeordneter Commits und Arbeitsaufgaben. Sie können Ihre DevOps-Workflows vollständig automatisieren, indem Sie Ereignisse für Ihre Ressourcen abonnieren.

Ressourcenschema

Ressourcen in YAML stellen Quellen von Pipelines, Builds, Repositorys, Containern, Paketen und Webhooks dar. Vollständige Schemainformationen finden Sie in der Ressourcendefinition in der YAML-Schemareferenz für Azure Pipelines.

Wenn eine Ressource eine Pipeline auslöst, werden die folgenden Variablen festgelegt:

resources.triggeringAlias
resources.triggeringCategory

Die Variable Build.Reason muss ResourceTrigger sein, damit diese Werte festgelegt werden. Die Werte sind leer, wenn eine Ressource die Pipelineausführung nicht ausgelöst hat.

Pipelines-Ressourcendefinition

Wenn Sie über eine Pipeline verfügen, die Artefakte erzeugt, können Sie die Artefakte nutzen, indem Sie eine pipelines-Ressource definieren. Nur Azure-Pipelines können die pipelines Ressource verwenden. Sie können Trigger für Ihre kontinuierlichen Bereitstellungsworkflows (CD) für eine Pipelineressource festlegen.

In Ihrer Ressourcendefinition ist ein eindeutiger Wert, den Sie verwenden können, pipeline um später in Ihrer Pipeline auf die Pipelineressource zu verweisen. Der source Name der Pipeline, die das Pipelineartefakt erzeugt hat. Vollständige Schemainformationen finden Sie in der Definition "resources.pipelines.pipelines.pipeline".

Sie verwenden die Bezeichnung, die durch pipeline den Verweis auf die Pipelineressource aus anderen Teilen Der Pipeline definiert ist, z. B. bei Verwendung von Pipelineressourcenvariablen oder Herunterladen von Artefakten. Eine alternative Möglichkeit zum Herunterladen von Pipelineartefakten finden Sie unter "Artefakte herunterladen".

Wichtig

Wenn Sie einen Pipelineressourcentrigger definieren:

• Wenn die pipeline Ressource aus demselben Repository wie die aktuelle Pipeline stammt oder selfdas Auslösen folgt demselben Verzweigung und Commit, für den das Ereignis ausgelöst wird.
• Wenn die Pipelineressource aus einem anderen Repository stammt, löst die aktuelle Pipeline im Standardbranch des pipeline Ressourcen-Repositorys aus.

Beispiel für Pipelineressourcendefinitionen

Im folgenden Beispiel werden Artefakte aus einer Pipeline innerhalb desselben Projekts verwendet.

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

Um eine Pipeline aus einem anderen Projekt zu nutzen, fügen Sie den Projektnamen und den Quellnamen ein. Im folgenden Beispiel wird branch die Standardversion aufgelöst, wenn die Pipeline manuell oder geplant ausgelöst wird. Die Verzweigungseingabe darf keine Wildcards enthalten.

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

Das folgende Beispiel zeigt eine Pipelineressource mit einem einfachen Trigger.

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

Das folgende Beispiel zeigt eine Pipelineressource trigger mit Verzweigungsbedingungen.

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

Im folgenden Beispiel werden Filter zum Auswerten von Triggerbedingungen für CD-Pipelines verwendet stages . Stufen verwenden den AND Operator. Nach erfolgreichem Abschluss aller bereitgestellten Phasen löst die CD-Pipeline aus.

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

Im folgenden Beispiel werden Filter für die Standardversionsauswertung und für Trigger verwendet tags . Tags verwenden den AND Operator.

Dies tags wird für die Kontinuierliche Integration (CI) oder CD-Pipeline festgelegt. Diese Tags unterscheiden sich von den Tags, die in Verzweigungen im Git-Repository festgelegt sind.

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

Versionsauswertung der Pipelinesartefakte

Die Artefaktversion der Ressourcenpipeline hängt davon ab, wie die Pipeline ausgelöst wird.

Manueller oder geplanter Trigger

Wenn die Pipelineausführung manuell ausgelöst oder geplant wird, definieren die Werte der version, branchund tags Eigenschaften die Artefaktversion. Die branch Eingabe darf keine Wildcards haben. Die tags Eigenschaften verwenden den AND Operator.

Angegebene Eigenschaften	Artefaktversion
version	Die Artefakte aus dem Build mit der angegebenen Ausführungsnummer
branch	Die Artefakte aus dem neuesten Build, der auf der angegebenen Verzweigung durchgeführt wurde
tags Liste	Die Artefakte aus dem neuesten Build mit allen angegebenen Tags
Liste branch und tags	Die Artefakte aus dem neuesten Build auf der angegebenen Verzweigung, die alle angegebenen Tags enthält
Keine	Die Artefakte aus dem neuesten Build in allen Branches.

In der folgenden pipeline Ressourcendefinition werden die Standardversion und tags die branch Eigenschaften verwendet, um die Standardversion zu bewerten, wenn die Pipeline manuell oder geplant ausgelöst wird. Wenn Sie die Pipeline manuell zum Ausführen auslösen, ist die MyCIAlias Pipelineartefakteversion der neueste Build für die main Verzweigung mit den Production Und-Tags PrepProduction .

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

Auslöser für den Abschluss der Ressourcenpipeline

Wenn eine Pipeline ausgelöst wird, weil eine ihrer Ressourcenpipelines abgeschlossen ist, ist die Artefaktversion die Version der auslösenden Pipeline. Die Werte der Eigenschaften version, branch und tags werden ignoriert.

Angegebene Trigger	Ergebnis
branches	Eine neue Pipelineausführung wird ausgelöst, wenn die Ressourcenpipeline erfolgreich eine Ausführung auf einem der include Verzweigungen abgeschlossen hat.
tags	Eine neue Pipelineausführung wird ausgelöst, wenn die Ressourcenpipeline erfolgreich eine ausführung abgeschlossen hat, die mit allen angegebenen Tags markiert ist.
stages	Eine neue Pipelineausführung wird ausgelöst, wenn die Ressourcenpipeline erfolgreich die angegebene stagesAusgeführt wird.
branches, tags und stages	Eine neue Pipelineausführung wird ausgelöst, wenn die Ressourcenpipeline alle Bedingungen für Verzweigung, Tags und Phasen erfüllt.
trigger: true	Eine neue Pipelineausführung wird ausgelöst, wenn die Ressourcenpipeline erfolgreich eine Ausführung abgeschlossen hat.
Nichts	Keine neuen Pipelineausführungsauslöser, wenn die Ressourcenpipeline eine Ausführung erfolgreich abgeschlossen hat.

Die folgende Pipeline wird immer dann ausgeführt, wenn die SmartHotel-CI Ressourcenpipeline ausgeführt wird:

• Wird auf einer der releases Zweige oder auf der main Verzweigung ausgeführt
• Ist mit beiden Verified und Signed
• Schließt sowohl die Phasen als PreProduction auch die Production Stufen ab.

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

Pipelineartefaktdownload

Der download Schritt lädt Artefakte herunter, die der aktuellen Ausführung oder einer anderen Pipelineressource zugeordnet sind.

Alle Artefakte aus der aktuellen Pipeline und alle zugehörigen pipeline Ressourcen werden automatisch heruntergeladen und zu Beginn jedes Bereitstellungsauftrags zur Verfügung gestellt. Sie können dieses Verhalten überschreiben, indem Sie diese noneEinstellung festlegen download oder einen anderen Pipelineressourcenbezeichner angeben.

Reguläre Auftragsartefakte werden nicht automatisch heruntergeladen. Verwenden Sie bei Bedarf explizit download.

Artefakte aus der pipeline Ressource werden in "$(PIPELINE)" heruntergeladen. WORKSPACE)/<pipeline-identifier/<artifact-identifier>> folder. Weitere Informationen finden Sie unter Veröffentlichen und Herunterladen von Pipelineartefakten.

Die optionale artifact Eigenschaft gibt Artefaktnamen an. Wenn nicht angegeben, werden alle verfügbaren Artefakte heruntergeladen. Die optionale patterns Eigenschaft definiert Muster, die enthaltende Dateien darstellen. Vollständige Schemainformationen finden Sie in der definition "steps.download".

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

Variablen der Pipelineressource

In jeder Ausführung sind die Metadaten für eine Pipelineressource für alle Aufträge als vordefinierte Variablen verfügbar. Diese Variablen sind nur zur Laufzeit für Ihre Pipeline verfügbar und können daher nicht in Vorlagenausdrücken verwendet werden, die zur Pipelinekompilierungszeit ausgewertet werden.

Weitere Informationen finden Sie unter Metadaten der Pipelineressource als vordefinierte Variablen. Weitere Informationen zur Variablensyntax finden Sie unter Definieren von Variablen.

Im folgenden Beispiel werden die vordefinierten Variablenwerte für die myresourcevars Pipelineressource zurückgegeben.

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)

Builds-Ressourcendefinition

Wenn Sie über ein externes CI-Buildsystem verfügen, das Artefakte erzeugt, können Sie Artefakte mit builds Ressourcen nutzen. Eine build Ressource kann von jedem externen CI-System wie Jenkins, TeamCity oder CircleCI stammen.

Die builds Kategorie ist erweiterbar. Sie können eine Erweiterung schreiben, um Artefakte von Ihrem Builddienst zu nutzen, und einen neuen Diensttyp als Teil von builds.

In der build Definition version wird standardmäßig der neueste erfolgreiche Build verwendet. Die trigger Option ist standardmäßig nicht aktiviert und muss explizit festgelegt werden. Vollständige Schemainformationen finden Sie in der definition "resources.builds.build".

Im folgenden Beispiel ist Jenkins die Ressource type.

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

Wichtig

Trigger werden nur für gehostete Jenkins unterstützt, wenn Azure DevOps eine Sichtlinie mit dem Jenkins-Server hat.

Die downloadBuild-Aufgabe

Die build Ressourcenartefakte werden nicht automatisch in Ihre Aufträge/Bereitstellungsaufträge heruntergeladen. Um Artefakte aus der build Ressource als Teil Ihrer Aufträge zu nutzen, müssen Sie den downloadBuild Vorgang explizit hinzufügen. Sie können das Downloadverhalten für jede Bereitstellung oder jeden Auftrag anpassen.

Dieser Vorgang wird automatisch in den entsprechenden Downloadvorgang für den Typ der build Ressource aufgelöst, die von der Laufzeit definiert wird. Artefakte aus der build Ressource werden in " $(PIPELINE)" heruntergeladen. WORKSPACE)/<build-identifier>/ folder.

In der downloadBuild Definition geben Sie die Ressource an, aus der Artefakte heruntergeladen werden sollen. Die optionale artifact Eigenschaft gibt Artefakte an, die heruntergeladen werden sollen. Wenn nicht angegeben, werden alle artefakte, die der Ressource zugeordnet sind, heruntergeladen.

Die optionale patterns Eigenschaft definiert einen Minimatch-Pfad oder eine Liste der minimatch-Pfade , die heruntergeladen werden sollen. Wenn leer, wird das gesamte Artefakt heruntergeladen. Der folgende Codeausschnitt lädt beispielsweise nur die Dateien *.zip herunter.

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

Vollständige Schemainformationen finden Sie in der definition "steps.downloadBuild".

Definition einer Repositoryressource

Mit dem repository-Schlüsselwort können Sie ein externes Repository angeben. Sie können diese Ressource verwenden, wenn Ihre Pipeline Vorlagen in einem anderen Repository enthält oder Sie das Auschecken mit mehreren Repositorys mit einem Repository verwenden möchten, das eine Dienstverbindung erfordert. Sie müssen das System über diese Repositorys informieren.

Zum Beispiel:

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

Vollständige Schemainformationen finden Sie in der Definition "resources.repository.repository".

Repositoryressourcentypen

Azure Pipelines unterstützt die folgenden Werte für den Repositorytyp: git, , github, githubenterprise, und bitbucket.

• Der git-Typ bezieht sich auf Azure Repos Git-Repositorys.
• GitHub Enterprise-Repositorys benötigen zur Autorisierung eine GitHub Enterprise-Dienstverbindung.
• Bitbucket Cloud-Repositorys benötigen eine Bitbucket Cloud-Dienstverbindung zur Autorisierung.

type	Name-Wert	Beispiel
type: git	Ein anderes Repository im selben Projekt oder derselben Organisation.	Gleiches Projekt: name: otherRepo Ein weiteres Projekt in derselben Organisation: name: otherProject/otherRepo.
type: github	Vollständiger Name des GitHub-Repositorys einschließlich des Benutzers oder der Organisation.	name: Microsoft/vscode
type: githubenterprise	Vollständiger Name des GitHub Enterprise-Repositorys, einschließlich des Benutzers oder der Organisation.	name: Microsoft/vscode
type: bitbucket	Vollständiger Name des Bitbucket-Cloud-Repositorys einschließlich des Benutzers oder der Organisation.	name: MyBitbucket/vscode

Repositoryressourcenvariablen

In jeder Ausführung sind die folgenden Metadaten für eine Repositoryressource für alle Aufträge in Form von Laufzeitvariablen verfügbar. Dies <Alias> ist der Bezeichner, den Sie Ihrer Repositoryressource zugeben.

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

Das folgende Beispiel verfügt über eine Repositoryressource mit einem Alias von common, sodass auf die Repositoryressourcenvariablen zugegriffen resources.repositories.common.*wird.

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)"

Auschecken des Schlüsselworts für Repositorys

Repositorys aus der repository-Ressource werden nicht automatisch in Ihren Aufträgen synchronisiert. Verwenden Sie das checkout Schlüsselwort, um ein Repository abzurufen, das als Teil der repository Ressource definiert ist. Vollständige Schemainformationen finden Sie in der Definition "steps.checkout".

Weitere Informationen finden Sie im Artikel zum Auschecken mehrerer Repositorys in Ihrer Pipeline.

Containerressourcendefinition

Wenn Sie Containerimages als Teil Ihrer CI/CD-Pipelines verwenden müssen, können Sie Ressourcen verwenden containers . Eine container Ressource kann eine öffentliche oder private Docker-Registrierung oder eine Azure Container Registry-Instanz sein.

Sie können ein generisches Containerressourcenimage als Teil Ihres Auftrags verwenden oder die Ressource für Containeraufträge verwenden. Wenn Ihre Pipeline die Unterstützung eines oder mehrerer Dienste erfordert, müssen Sie Dienstcontainer erstellen und eine Verbindung herstellen. Sie können Volumes verwenden, um Daten zwischen Diensten freizugeben.

Wenn Sie Bilder aus einer Docker-Registrierung als Teil Ihrer Pipeline verwenden müssen, können Sie eine generische Containerressource definieren. Es ist kein type Schlüsselwort erforderlich. Zum Beispiel:

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

Vollständige Schemainformationen finden Sie in der Definition "resources.containers.container".

Hinweis

Die enabled: 'true' Syntax zum Aktivieren von Containertriggern für alle Imagetags unterscheidet sich von der Syntax für andere Ressourcentrigger. Achten Sie darauf, die richtige Syntax für bestimmte Ressourcen zu verwenden.

Azure Container Registry-Ressourcentyp

Um Ihre Azure-Containerregistrierungsimages zu nutzen, können Sie den Ressourcentyp acr"first-class container" verwenden. Sie können diesen Ressourcentyp als Teil Ihrer Aufträge verwenden und automatische Pipelinetrigger aktivieren.

Sie benötigen Die Berechtigungen "Mitwirkender" oder "Besitzer " für die Azure-Containerregistrierung, um automatische Pipelinetrigger zu verwenden. Weitere Informationen finden Sie unter Azure Container Registry: Rollen und Berechtigungen.

Um den acr Ressourcentyp zu verwenden, müssen Sie die azureSubscriptionWerte resourceGroupund Werte repository für Ihre Azure-Containerregistrierung angeben. Zum Beispiel:

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

Hinweis

Dienstverbindungen, die den Workload-Identitätsverbund verwenden, werden in azureSubscriptionnicht unterstützt.

Containerressourcenvariablen

Nachdem Sie einen Container als Ressource definiert haben, werden Containerimagemetadaten als Variablen an die Pipeline übergeben. Informationen wie Image, Registrierung und Verbindungsdetails sind für alle Aufträge verfügbar, die in Ihren Containerbereitstellungsaufgaben verwendet werden.

Containerressourcenvariablen funktionieren mit Docker und Azure Container Registry. Sie können keine Containerressourcenvariablen für lokale Imagecontainer verwenden. Die location Variable gilt nur für den acr Typ der Containerressourcen.

Das folgende Beispiel verfügt über eine Azure Resource Manager-Dienstverbindung mit dem Namen arm-connection. Weitere Informationen finden Sie unter Azure-Containerregistrierungen, Repositorys und Images.

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)

Paketressourcendefinition

Sie können NuGet- und npm GitHub-Pakete als Ressourcen in YAML-Pipelines nutzen. Um automatisierte Pipelinetrigger zu aktivieren, wenn eine neue Paketversion freigegeben wird, legen Sie die trigger Eigenschaft auf true.

Wenn Sie Ressourcen definierenpackage, geben Sie das Paket-Repository>/<den Namen <> in der name Eigenschaft an, und legen Sie das Paket type als NuGet oder festnpm. Um GitHub-Pakete zu verwenden, verwenden Sie die pat-basierte Authentifizierung (Personal Access Token), und erstellen Sie eine GitHub-Dienstverbindung, die den PAT verwendet.

Vollständige Schemainformationen finden Sie in der Definition "resources.packages.package".

Standardmäßig werden Pakete nicht automatisch in Aufträge heruntergeladen. Verwenden Sie getPackage, um es herunterzuladen.

Das folgende Beispiel verfügt über eine GitHub-Dienstverbindung mit dem Namen pat-contoso eines GitHub npm-Pakets.contoso Weitere Informationen finden Sie unter GitHub-Pakete.

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

Webhooks-Ressourcendefinition

Hinweis

Webhooks wurden in Azure DevOps Server 2020.1 veröffentlicht.

Sie können Artefakte nutzen und automatisierte Trigger mit Pipeline-, Container-, Build- und Paketressourcen aktivieren. Sie können diese Ressourcen jedoch nicht verwenden, um Ihre Bereitstellungen basierend auf externen Ereignissen oder Diensten zu automatisieren.

Mit der webhooks Ressource in YAML-Pipelines können Sie Ihre Pipelines in externe Dienste wie GitHub, GitHub Enterprise, Nexus und Artifactory integrieren, um Workflows zu automatisieren. Sie können alle externen Ereignisse über Webhooks abonnieren und die Ereignisse verwenden, um Ihre Pipelines auszulösen.

Webhooks automatisieren Ihren Workflow basierend auf jedem externen Webhook-Ereignis, das von erstklassigen Ressourcen wie Pipelines, Builds, Containern oder Paketen nicht unterstützt wird. Außerdem können Sie für lokale Dienste, bei denen Azure DevOps keinen Einblick in den Prozess hat, Webhooks für den Dienst konfigurieren und Ihre Pipelines automatisch auslösen.

Um ein Webhook-Ereignis zu abonnieren, definieren Sie eine Webhook-Ressource in Ihrer Pipeline und zeigen sie auf eine eingehende Webhook-Dienstverbindung. Sie können auch weitere Filter für die Webhookressource definieren, die auf den JSON-Nutzdaten basieren, um die Trigger für die einzelnen Pipelines anzupassen.

Wenn die eingehende Webhook-Dienstverbindung ein Webhook-Ereignis empfängt, löst ein neuer Ausführungsauslöser für alle Pipelines aus, die das Webhook-Ereignis abonniert haben. Sie können die JSON-Nutzlastdaten in Ihren Aufträgen als Variablen verwenden, indem Sie das Format ${{ parameters.<WebhookAlias>.<JSONPath>}}verwenden.

Vollständige Schemainformationen finden Sie in der Definition "resources.webhooks.webhook".

Im folgenden Beispiel wird eine Webhook-Ressource definiert:

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

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

Webhooktrigger

Um Webhook-Trigger zu konfigurieren, richten Sie zuerst einen Webhook für Ihren externen Dienst ein, und stellen die folgenden Informationen bereit:

• Anforderungs-URL: https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
• Geheimer Schlüssel (Optional): Wenn Sie Ihre JSON-Nutzlast sichern müssen, geben Sie einen geheimen Wert an.

Als Nächstes erstellen Sie eine neue eingehende Webhook-Dienstverbindung. Für diesen Dienstverbindungstyp definieren Sie die folgenden Informationen:

• WebHook-Name: Identisch mit dem webhook, der in Ihrem externen Dienst erstellt wurde.
• Geheimer Schlüssel (Optional): Wird verwendet, um den HMAC-SHA1-Hash der Nutzlast zur Überprüfung der eingehenden Anforderung zu überprüfen. Wenn Sie beim Erstellen Ihres Webhooks einen geheimen Schlüssel verwendet haben, müssen Sie denselben geheimen Schlüssel angeben.
• Http-Header: Der HTTP-Header in der Anforderung, der den HMAC-SHA1-Hashwert der Nutzlast für die Anforderungsüberprüfung enthält. Beispielsweise lautet X-Hub-Signatureder GitHub-Anforderungsheader .

Um Ihre Pipeline mit einem Webhook auszulösen, stellen Sie eine POST Anforderung an https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview. Dieser Endpunkt ist öffentlich verfügbar und benötigt keine Autorisierung. Die Anforderung sollte einen Text wie das folgende Beispiel aufweisen:

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

Hinweis

Der Zugriff auf Daten aus dem Anforderungstext des Webhooks kann zu einem falschen YAML führen. Beispielsweise ruft der Pipelineschritt - script: echo ${{ parameters.WebHook.resource.message }} die gesamte JSON-Nachricht ab, die ungültige YAML generiert. Jede pipeline, die über diesen Webhook ausgelöst wird, wird nicht ausgeführt, da das generierte YAML ungültig wurde.

Der folgende Codeausschnitt zeigt ein weiteres Beispiel, in dem Webhook-Filter verwendet werden.

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

Manuelle Versionsauswahl für Ressourcen

Wenn Sie eine CD-YAML-Pipeline manuell auslösen, wertet Azure Pipelines automatisch die Standardversionen für die in der Pipeline definierten Ressourcen basierend auf den bereitgestellten Eingaben aus. Azure Pipelines berücksichtigt jedoch, dass ci nur erfolgreich abgeschlossen wurde, wenn die Standardversion für geplante Trigger ausgewertet wird, oder wenn Sie keine Version manuell auswählen.

Sie können die Ressourcenversionsauswahl verwenden, um beim Erstellen einer Ausführung manuell eine andere Version auszuwählen. Die Ressourcenversionsauswahl wird für Pipeline-, Build-, Repository-, Container- und Paketressourcen unterstützt.

Für Pipelineressourcen können Sie alle verfügbaren Vorgänge in allen Verzweigungen anzeigen, sie basierend auf der Pipelinenummer oder Verzweigung durchsuchen und eine Ausführung auswählen, die erfolgreich, fehlgeschlagen oder in Bearbeitung ist. Diese Flexibilität stellt sicher, dass Sie Ihre CD-Pipeline ausführen können, wenn Sie sicher sind, dass eine Ausführung alle benötigten Artefakte erzeugt hat. Sie müssen nicht warten, bis eine CI-Ausführung abgeschlossen ist, oder sie aufgrund eines nicht verknüpften Phasenfehlers erneut ausführen.

Um die Ressourcenversionsauswahl zu verwenden, wählen Sie im Pipelinebereich "Ausführen" die Option "Ressourcen" und dann eine Ressource und eine bestimmte Version aus der Liste der verfügbaren Versionen aus.

Für Ressourcen, für die Sie keine verfügbaren Versionen abrufen können, z. B. GitHub-Pakete, stellt die Versionsauswahl ein Textfeld bereit, damit Sie die Version für die Ausführung eingeben können, um sie auszuwählen.

Ressourcenautorisierung in YAML-Pipelines

Ressourcen müssen autorisiert werden, bevor sie in Pipelines verwendet werden können. Ressourcenbesitzer steuern die Benutzer und Pipelines, die auf ihre Ressourcen zugreifen können. Es gibt mehrere Möglichkeiten, eine YAML-Pipeline für die Verwendung von Ressourcen zu autorisieren.

• Verwenden Sie die Ressourcenverwaltungsoberfläche, um alle Pipelines für den Zugriff auf die Ressource zu autorisieren. Variablengruppen und sichere Dateien werden beispielsweise auf der Bibliotheksseite unter Pipelines verwaltet, und Agentpools und Dienstverbindungen werden in den Project-Einstellungen verwaltet. Diese Autorisierung ist praktisch, wenn Sie den Zugriff auf Ressourcen, z. B. für Testressourcen, nicht einschränken müssen.

• Wenn Sie eine Pipeline erstellen, werden alle Ressourcen, auf die in der YAML-Datei verwiesen wird, automatisch für die Verwendung durch die Pipeline autorisiert, wenn Sie über die Rolle "Benutzer " für diese Ressourcen verfügen.

• Wenn Sie einer YAML-Datei eine Ressource hinzufügen und der Build mit einem Fehler fehlschlägt, wird Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.eine Option zum Autorisieren der Ressourcen für den fehlerhaften Build angezeigt.

  Wenn Sie Mitglied der Benutzerrolle für die Ressource sind, können Sie diese Option auswählen und die Ressource für den fehlerhaften Build autorisieren. Nachdem die Ressource autorisiert wurde, können Sie einen neuen Build starten.

• Überprüfen Sie, ob die Agentpoolsicherheitsrollen für Ihr Projekt korrekt sind.

Genehmigungsprüfungen für Ressourcen

Sie können Genehmigungsprüfungen und Vorlagen verwenden, um manuell zu steuern, wann eine Ressource ausgeführt wird. Mit der erforderlichen Vorlagengenehmigungsprüfung können Sie festlegen, dass jede Pipeline, die eine Ressource oder Umgebung verwendet, aus einer bestimmten YAML-Vorlage erweitert wird.

Das Festlegen einer erforderlichen Vorlagengenehmigung stellt sicher, dass Ihre Ressource nur unter bestimmten Bedingungen verwendet wird und die Sicherheit verbessert. Weitere Informationen zur Verbesserung der Pipelinesicherheit mit Vorlagen finden Sie unter Verwenden von Vorlagen zur Sicherheit.

Nachverfolgbarkeit

Azure Pipelines bietet vollständige Rückverfolgbarkeit für alle Ressourcen, die auf Pipeline- oder Bereitstellungsauftragsebene verbraucht werden.

Nachverfolgbarkeit von Pipelines

Azure Pipelines zeigt die folgenden Informationen für jede Pipelineausführung:

• Wenn eine Ressource die Pipeline ausgelöst hat, wird die Ressource, die die Pipeline ausgelöst hat, ausgelöst.
• Die Ressourcenversion und die verbrauchten Artefakte.
• Den jeweiligen Ressourcen zugeordnete Commits.
• Den jeweiligen Ressourcen zugeordnete Arbeitselemente.

Nachverfolgbarkeit von Umgebungen

Wenn eine Pipeline in einer Umgebung bereitgestellt wird, können Sie eine Liste der verbrauchten Ressourcen anzeigen. Die Ansicht enthält Ressourcen, die als Teil der Bereitstellungsaufträge und der zugehörigen Commits und Arbeitsaufgaben verbraucht werden.

Zugehörige CD-Pipelines-Informationen in CI-Pipelines

Um die End-to-End-Rückverfolgbarkeit zu ermöglichen, können Sie nachverfolgen, welche CD-Pipelines eine bestimmte CI-Pipeline über die pipelines Ressource verbrauchen. Wenn andere Pipelines Ihre CI-Pipeline nutzen, wird in der Ansicht "Ausführen" eine Registerkarte "Zugeordnete Pipelines" angezeigt. In der Ansicht werden alle CD-YAML-Pipelineläufe angezeigt, die Ihre CI-Pipeline und die Artefakte davon genutzt haben.

Ressourcenauslöserprobleme

Ressourcentrigger können nicht ausgeführt werden, weil:

• Die Quelle der bereitgestellten Dienstverbindung ist ungültig, es gibt Syntaxfehler im Trigger, oder der Trigger ist nicht konfiguriert.
• Triggerbedingungen werden nicht übereinstimmen.

Um zu sehen, warum Pipelinetrigger nicht ausgeführt werden konnten, wählen Sie das Menüelement "Probleme auslösen" auf der Pipelinedefinitionsseite aus. Triggerprobleme sind nur für nichtpository-Ressourcen verfügbar.

Auf der Seite "Triggerprobleme " beschreiben die Fehlermeldungen und Warnmeldungen, warum der Trigger fehlgeschlagen ist.

Häufig gestellte Fragen

Wann sollte ich Pipelineressourcen, die Downloadverknüpfung oder die Aufgabe "Pipelineartefakte herunterladen" verwenden?

Die Verwendung einer pipelines-Ressource ist eine Möglichkeit, Artefakte aus einer CI-Pipeline zu nutzen und auch automatisierte Trigger zu konfigurieren. Eine Ressource bietet Ihnen vollständige Einblicke in den Prozess, indem die verbrauchte Version, Artefakte, Commits und Arbeitselemente angezeigt werden. Wenn Sie eine Pipelineressource definieren, werden die zugehörigen Artefakte automatisch in Bereitstellungsaufträgen heruntergeladen.

Sie können die download Verknüpfung verwenden, um die Artefakte in Buildaufträgen herunterzuladen oder das Downloadverhalten in Bereitstellungsaufträgen außer Kraft zu setzen. Weitere Informationen finden Sie in der definition "steps.download".

Die Aufgabe "Pipelineartefakte herunterladen" bietet keine Rückverfolgbarkeit oder Trigger, aber manchmal ist es sinnvoll, diese Aufgabe direkt zu verwenden. Sie können beispielsweise eine Skriptaufgabe in einer anderen Vorlage speichern, für die Artefakte aus einem Build heruntergeladen werden müssen. Oder Sie möchten einer Vorlage möglicherweise keine Pipelineressource hinzufügen. Um Abhängigkeiten zu vermeiden, können Sie die Aufgabe „Pipelineartefakte herunterladen“ verwenden, um alle Buildinformationen an eine Aufgabe zu übergeben.

Wie kann ich eine Pipelineausführung auslösen, wenn mein Docker Hub-Image aktualisiert wird?

Der Containerressourcentrigger ist für Docker Hub für YAML-Pipelines nicht verfügbar, daher müssen Sie eine klassische Releasepipeline einrichten.

1. Erstellen Sie eine neue Docker Hub-Dienstverbindung.
2. Erstellen Sie eine klassische Releasepipeline, und fügen Sie ein Docker Hub-Artefakt hinzu. Legen Sie Ihre Dienstverbindung fest, und wählen Sie den Namespace, das Repository, die Version und den Quellalias aus.
3. Wählen Sie den Trigger aus, und schalten Sie den Continuous Deployment-Trigger auf Aktivieren um. Jeder Docker-Push, der in das ausgewählte Repository eintritt, erstellt eine Version.
4. Erstellen Sie eine neue Phase und einen neuen Auftrag. Fügen Sie zwei Aufgaben hinzu, Docker-Anmeldung und Bash.
   • Die Docker-Aufgabe verfügt über die login Aktion und meldet Sie bei Docker Hub an.
   • Die Bash-Aufgabe führt docker pull <hub-user>/<repo-name>[:<tag>] aus.

Wie kann ich meinen Webhook überprüfen und beheben?

1. Erstellen Sie eine Dienstverbindung.

2. Verweisen Sie im Abschnitt webhooks auf Ihre Dienstverbindung, und benennen Sie Ihren Webhook.

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

3. Führen Sie Ihre Pipeline aus. Der Webhook wird in Azure als verteilte Aufgabe für Ihre Organisation erstellt.

4. Führen Sie einen POST-API-Aufruf mit gültigem JSON im Textkörper für https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion> aus. Wenn Sie eine Antwort mit dem Statuscode 200 erhalten, ist Ihr Webhook bereit, von Ihrer Pipeline genutzt zu werden.

Wenn Sie eine 500-Statuscodeantwort mit dem Fehler Cannot find webhook for the given webHookId ...erhalten, befindet sich ihr Code möglicherweise in einer Verzweigung, die nicht Ihre Standardbranch ist. Um dieses Problem zu lösen:

1. Wählen Sie "Bearbeiten " auf Der Pipelineseite aus.
2. Wählen Sie im Menü "Weitere Aktionen " die Option "Trigger" aus.
3. Wählen Sie die Registerkarte "YAML " und dann " Quellen abrufen" aus.
4. Aktualisieren Sie unter "Standardverzweigung" für manuelle und geplante Builds Ihre Featurebranch.
5. Wählen Sie Save & queue (Speichern und in Warteschlange einreihen) aus.
6. Nachdem diese Pipeline erfolgreich ausgeführt wurde, führen Sie einen POST-API-Aufruf mit gültigem JSON im Textkörper für https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion> aus. Sie sollten jetzt eine Antwort mit dem Statuscode 200 erhalten.

Zugehöriger Inhalt

• Informationen zu Ressourcen für Azure-Pipelines
• Definieren von Variablen
• Hinzufügen und Verwenden von Variablengruppen
• Erstellen einer Umgebung und Verwenden der Umgebung als Ziel
• Verwenden des YAML-Pipeline-Editors
• YAML-Schemareferenz