Ressourcen in YAML-Pipelines

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

In diesem Artikel werden Ressourcen für YAML-Pipelines erläutert. Eine Ressource ist alles, was eine Pipeline verwendet, die außerhalb dieser Pipeline vorhanden ist. Ressourcen in YAML-Pipelines können andere Pipelines, Builds, Container, Pakete, Repositorys oder Webhooks sein.

Nachdem Sie eine Ressource definiert haben, können Sie sie überall in Ihrer Pipeline verwenden. Weitere Informationen und Beispiele finden Sie unter Ressourcendefinitionen.

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

Sie können den Ressourcenstatus verwenden, um Pipelines automatisch auszulösen , indem Sie die trigger Eigenschaft in der Ressourcendefinition festlegen. Die Pipeline resources.triggeringAlias und resources.triggeringCategory Variablen werden dann auf den Ressourcennamen und die Kategorie festgelegt. Diese Variablen sind leer, es sei denn, die Build.Reason Variable ist auf ResourceTrigger.

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

Ressourcenautorisierung

Ressourcen müssen für die Verwendung in Pipelines autorisiert sein. Ressourcenbesitzer kontrollieren 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 Verwaltungseinstellungen der Ressource, um Zugriffsberechtigungen für alle Pipelines zu erteilen. Sie können beispielsweise sichere Dateien und variablen Gruppen auf der Seite "Pipelines>Library" sowie Agentpools und Dienstverbindungen in Project-Einstellungspipelines> verwalten. Diese Autorisierung eignet sich für Ressourcen, die Sie nicht einschränken müssen, z. B. Testressourcen.

• Stellen Sie sicher, dass Sie mindestens über die Benutzerrolle in den Sicherheitsrollen des Agentpools für Ihr Projekt verfügen. YaML-Pipelines, die Sie erstellen, sind automatisch für die Verwendung von Ressourcen autorisiert, in denen Sie über die Benutzerrolle verfügen.

• Wenn Sie einer YAML-Pipeline eine Ressourcendefinition hinzufügen, aber der Build mit einem Fehler fehlschlägt, Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for usestellen Sie sicher, dass Sie mindestens über die Rolle "Benutzer " für die Ressource verfügen. Anschließend können Sie die Option auswählen, um die Ressourcen für den fehlerhaften Build zu autorisieren. Sobald die Ressource autorisiert ist, können Sie einen neuen Build starten.

Genehmigungsüberprüfungen für Ressourcen

Sie können Genehmigungsprüfungen und Vorlagen verwenden, um die Ressourcenverwendung manuell zu steuern. Mithilfe der erforderlichen Vorlagengenehmigungsprüfung können Sie eine beliebige Pipeline benötigen, die eine bestimmte Ressource oder Umgebung verwendet, um von einer bestimmten YAML-Vorlage zu erweitern.

Das Festlegen einer erforderlichen Vorlagengenehmigung erhöht die Sicherheit, indem sichergestellt wird, dass Ihre Ressource nur unter bestimmten Bedingungen verwendet wird. Weitere Informationen finden Sie unter Verwenden von Vorlagen für die Sicherheit.

Manuelle Ressourcenversionsauswahl

Azure Pipelines wertet die Standardversionen für Ressourcen basierend auf ihren Ressourcendefinitionen aus. Bei geplanten Ausführungen oder manuellen Ausführungen, wenn Sie eine Ausführung nicht manuell auswählen, berücksichtigt Azure Pipelines nur die ausführung erfolgreich abgeschlossene fortlaufende Integration (CI) für die Auswertung der Standardressourcenversionen.

Sie können die manuelle Ressourcenversionsauswahl verwenden, um verschiedene Ressourcenversionen auszuwählen, wenn Sie eine YAML-Pipeline für die kontinuierliche Bereitstellung (CD) manuell auslösen. Die Ressourcenversionsauswahl wird für Pipeline-, Build-, Repository-, Container- und Paketressourcen unterstützt.

Bei pipeline Ressourcen können Sie mit der manuellen Versionsauswahl alle verfügbaren Läufe in allen Verzweigungen anzeigen, die Ausführung basierend auf der Pipelinenummer oder Verzweigung durchsuchen und eine ausführung auswählen, die erfolgreich, fehlgeschlagen oder in Bearbeitung ist.

Sie müssen nicht warten, bis eine CI-Ausführung abgeschlossen ist, oder sie aufgrund eines nicht zusammenhängenden Fehlers erneut ausführen, bevor Sie die CD-Pipeline ausführen können. Sie haben die Flexibilität, jede Ausführung auszuwählen, von der Sie wissen, dass Sie die benötigten Artefakte erstellt haben.

Um die Ressourcenversionsauswahl zu verwenden, wählen Sie " Ressourcen " im Pipelinebereich "Ausführen " aus, wählen Sie eine Ressource aus, und wählen Sie 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, können Sie Ihre gewünschte Version in das Textfeld eingeben.

Ressourcendefinitionen

YaML-Pipelineressourcen können folgende Sein:

• Andere Pipelines
• Builds
• Behälter
• Pakete
• Repositorys oder
• Webhooks.

Die folgenden Abschnitte enthalten Definitionen und Beispiele für die YaML-Pipelineressourcenkategorien. Vollständige Schemainformationen finden Sie in der Ressourcendefinition in der YAML-Schemareferenz für Azure Pipelines.

Pipelines-Ressource

Sie können CI-Ressourcen pipeline als Trigger für Ihre CD-Workflows verwenden. Sie können auch auf Ressourcen aus Ihrer Pipeline verweisen pipeline , um Artefakte herunterzuladen oder Pipelineressourcenvariablen zu verwenden. Nur Azure-Pipelines können die pipelines Ressource verwenden.

In der pipelines Ressourcendefinition:

• pipeline ist ein eindeutiger Name, den Sie verwenden, um auf die Pipelineressourcen zu verweisen.
• source ist der Name der Pipeline, die die Pipelineartefakte erzeugt hat.

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

Beispiel für Pipelineressourcendefinitionen

Im folgenden Beispiel verwendet die Ressourcendefinition Artefakte aus einer Pipeline innerhalb desselben Azure DevOps-Projekts.

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 anzugeben, fügen Sie den project Namen in die Ressourcendefinition ein. Im folgenden Beispiel wird branch auch die Standardversion aufgelöst, wenn die Pipeline manuell oder nach Zeitplan ausgelöst wird. Die Verzweigungseingabe darf keine Wildcards enthalten.

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

Ressourcenversionsauswertung

Azure Pipelines wertet die Standardversionen für Ressourcen basierend auf ihren Ressourcendefinitionen aus. Die Standardversionen eines Ressourcenartefaktes einer Pipeline hängen davon ab, ob die Pipeline manuell oder nach Zeitplan ausgeführt wird oder basierend auf dem Ergebnis der Ressourcenausführung triggert .

Bei einer manuellen oder geplanten Pipelineausführung definieren die Werte des versionTyps , branchund tags die Eigenschaften in der pipeline Ressourcendefinition die Artefaktversionen. Die branch Eingabe darf keine Wildcards enthalten, und die tags Eigenschaften verwenden den AND Operator.

Bei geplanten Ausführungen oder manuellen Ausführungen, wenn Sie die Versionsauswahl nicht verwenden, berücksichtigt Azure Pipelines beim Auswerten der Standardressourcenversionen nur die ausführung der fortlaufenden Integration (Continuous Integration, CI) erfolgreich abgeschlossen. Bei manuellen Ausführungen können Sie die definierten Versionen überschreiben, indem Sie die manuelle Versionsauswahl verwenden.

In der folgenden Tabelle sind pipeline ressourcendefinitionseigenschaften und die artefaktversionen aufgeführt, die sie angeben.

In der folgenden pipeline Ressourcendefinition werden die Standardversion und branch die tags Eigenschaften verwendet, um die Standardversion auszuwerten, wenn die Pipeline manuell geplant oder ausgelöst wird. Die myCIAlias Artefaktversion ist der neueste Build für die main Verzweigung mit den Production Tags.PreProduction

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

Pipelineressourcentrigger

Bei Pipelineausführungen, die für das Ergebnis einer Ressourcenausführung ausgelöst werden, bestimmen die trigger Eigenschafteneinstellungen in der Ressourcendefinition die Standardversionen des Ressourcenartefakts. Um eine pipeline Ressource als Trigger zum Ausführen der aktuellen Pipeline zu verwenden, müssen Sie die trigger Eigenschaft festlegen. Wenn Sie keine Eigenschaft einschließen trigger , lösen Ressourcenausführungen keine aktuelle Pipelineausführung aus.

Wenn eine Pipeline basierend auf einem trigger Wert in einer pipeline Ressourcendefinition ausgelöst wird, werden die Werte der allgemeinen Ressourcendefinition versionund branchtags Eigenschaften ignoriert. Die trigger Eigenschaften bestimmen die Artefaktversionen.

In der folgenden Tabelle wird beschrieben, wie sich die Eigenschaften auf das trigger Triggerverhalten auswirken.

Das folgende Beispiel zeigt eine Pipelines-Ressourcendefinition mit einer einfachen trigger.

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

Das folgende Beispiel zeigt eine Pipelineressource trigger mit Verzweigungsbedingungen.

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

Im folgenden Beispiel werden stages Filter verwendet, um Triggerbedingungen für CD-Pipelines auszuwerten. Auslöser stages verwenden den AND Operator. Die CD-Pipeline löst nach erfolgreichem Abschluss aller aufgeführten Phasen aus.

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

Im folgenden Beispiel werden Filter für die Standardversionsauswertung und für den Trigger verwendet tags . Die trigger Tags verwenden den AND Operator. Der tags Satz in pipeline Ressourcendefinitionen unterscheidet sich von den Tags, die in Verzweigungen im Git-Repository festgelegt sind.

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

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 Production auch die PreProduction Stufen ab.

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

Pipeline-Artefakt-Download

Sie können den download Schritt in einer YAML-Pipeline verwenden, um Artefakte herunterzuladen, die der aktuellen Ausführung oder einer anderen pipeline Ressource zugeordnet sind.

Artefakte werden automatisch nur in Bereitstellungsaufträgen heruntergeladen. Alle Artefakte aus der aktuellen Pipeline und alle zugehörigen pipeline Ressourcen werden automatisch heruntergeladen und stehen zu Beginn jedes Bereitstellungsauftrags zur Verfügung. Sie können dieses Verhalten überschreiben, indem Sie diese downloadEinstellung festlegen none oder einen anderen pipeline Ressourcenbezeichner angeben.

In einem regulären Buildauftrag werden Artefakte nicht automatisch heruntergeladen. Verwenden Sie bei Bedarf explizit download.

In diesem download Schritt gibt die optionale artifact Eigenschaft Artefaktnamen an. Wenn nicht angegeben, werden alle verfügbaren Artefakte heruntergeladen.

Die optionale patterns Eigenschaft definiert Muster, die Dateien darstellen, die heruntergeladen werden sollen. Vollständige Schemainformationen finden Sie in der definition "steps.download ".

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

Artefakte aus dem pipeline Ressourcendownload auf $(PIPELINE). WORKSPACE)/<pipeline-identifier/>artifact-identifier<> folder. Weitere Informationen finden Sie unter Pipeline-Artefakte veröffentlichen und herunterladen. Eine alternative Möglichkeit zum Herunterladen von Pipelineartefakten finden Sie unter Artefakte herunterladen.

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

Wenn Sie über ein CI-Buildsystem verfügen, das Artefakte erzeugt, können Sie die Artefakte mit builds Ressourcen nutzen.

Die builds Kategorie ist erweiterbar. Eine build-Ressource kann aus einem beliebigen externen CI-System wie Jenkins, TeamCity oder CircleCI sein. Sie können eine Erweiterung schreiben builds , um Artefakte von Ihrem Builddienst zu nutzen oder einen neuen Diensttyp einzuführen.

In der build Definition version wird standardmäßig der neueste erfolgreiche Build verwendet. Sie müssen bei Bedarf explizit festlegen trigger . Vollständige Schemainformationen finden Sie in der definition "resources.builds.build ".

Im folgenden Beispiel ist Jenkins der Ressourcentyp.

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

Die downloadBuild-Aufgabe

Die build Ressourcenartefakte werden nicht automatisch auf 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.

Der downloadBuild Vorgang wird automatisch in den entsprechenden Downloadvorgang für den Typ der build Ressource aufgelöst, die von der Laufzeit definiert wird. Artefakte aus dem build Ressourcendownload auf $ (PIPELINE). 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 dem Ressourcendownload zugeordnet sind, zugeordnet.

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

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

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

Repository-Ressource

Verwenden Sie das repository Schlüsselwort, um das System über externe Repositorys zu informieren, wenn:

• Ihre Pipeline verfügt über Vorlagen in einem anderen Repository.
• Sie möchten das Auschecken mit mehreren Repositorys mit einem Repository verwenden, das eine Dienstverbindung erfordert.

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 gitTypen , github, githubenterpriseund bitbucket Repositorys.

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

In der folgenden Tabelle werden die repository Ressourcentypen beschrieben:

Repositoryressourcenvariablen

resources.repositories.<alias>.name
resources.repositories.<alias>.ref
resources.repositories.<alias>.type
resources.repositories.<alias>.id
resources.repositories.<alias>.url

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

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

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

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

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. Sie können das checkout Schlüsselwort verwenden, um ein repository abzurufen, das in einer repository Ressource definiert ist. Weitere Informationen finden Sie im Artikel zum Auschecken mehrerer Repositorys in Ihrer Pipeline. Vollständige Schemainformationen finden Sie in der Definition "steps.checkout" .

Containerressource

Sie können Ressourcen verwenden containers , um Containerimages in Ihren CI/CD-Pipelines zu nutzen. Eine container Ressource kann eine öffentliche oder private Docker-Registrierung oder eine Azure Containerregistrierungs-Instanz sein.

Sie können ein generisches Containerressourcenimage als Teil Ihrer Aufträge nutzen oder in Containeraufträgen verwenden. Wenn Ihre Pipeline die Unterstützung eines oder mehrerer Dienste erfordert, müssen Sie auch Dienstcontainer erstellen und eine Verbindung mit diesen herstellen. Sie können Volumes verwenden, um Daten zwischen Diensten gemeinsam nutzen zu können.

Wenn Sie Bilder aus einer Docker-Registrierung verwenden müssen, können Sie eine generische Containerressource definieren, ohne ein type Schlüsselwort zu verwenden. Zum Beispiel:

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

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

Azure Container Registry-Ressourcentyp

Um Ihre Azure Container Registry-Images zu nutzen, können Sie den Container-Ressourcentyp erster Klasse acr verwenden. Sie können diesen Ressourcentyp in Ihren Aufträgen verwenden und automatische Pipelinetrigger aktivieren.

Sie benötigen Azure Container Registry-Mitwirkender oder Besitzerberechtigungen , 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* 

Containerressourcenvariablen

Sobald Sie einen Container als Ressource definieren, werden Containerimage-Metadaten als Variablen an die Pipeline übergeben. Informationen wie Image, Registrierung und Verbindungsdetails sind für alle Aufträge zugänglich, die Sie für Ihre Aufgaben zur Bereitstellung von Containern verwenden.

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

Das folgende Beispiel hat eine Azure Resource Manager-Dienstverbindung namens 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)

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

steps:
- getPackage: contoso

resources:
  webhooks:
    - webhook: myWebhookResource
      connection: myWebHookConnection

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

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

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

Nachverfolgbarkeit

Azure Pipelines bieten vollständige Nachverfolgbarkeit für jede Ressource, die auf Pipelineebene oder der Ebene des Bereitstellungsauftrags genutzt wird. Azure Pipelines zeigt die folgenden Informationen für jede Pipelineausführung, die Ressourcen verwendet:

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

Zugehörige CD-Pipelineinformationen für 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 verbraucht haben. Wenn andere Pipelines Ihre CI-Pipeline verbraucht haben, wird in der Ansicht "Ausführen" eine Registerkarte "Zugeordnete Pipelines" angezeigt. In der Ansicht werden alle CD-YAML-Pipelineausführungen angezeigt, die Ihre CI-Pipeline und die Artefakte davon genutzt haben.

Nachverfolgbarkeit von Umgebungen

Nachdem eine Pipeline in einer Umgebung bereitgestellt wurde, können Sie eine Liste der ressourcen anzeigen, die sie verbraucht hat, sowie deren zugeordnete Commits und Arbeitsaufgaben.

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 Build-Aufträgen herunterzuladen oder um das Download-Verhalten 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önnten z. B. eine Skriptaufgabe in einer anderen Vorlage, die das Herunterladen von Artefakten aus einem Build erfordert, gespeichert haben. 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 erfolgt, erzeugt ein Release.
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 meine Webhooks überprüfen und mögliche Probleme 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 Antwort mit dem Statuscode 500 mit dem Fehler Cannot find webhook for the given webHookId ... erhalten, befindet sich Ihr Code möglicherweise in einem Branch, der nicht Ihr Standardbranch ist. Um dieses Problem zu lösen:

1. Wählen Sie Bearbeiten in Ihrer Pipelineseite.
2. Wählen Sie im Menü Weitere Aktionen die Option Auslöser aus.
3. Wählen Sie die Registerkarte YAML und dann Quellen abrufen.
4. Unter Standardbranch für manuelle und geplante Builds, aktualisieren Sie Ihren 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.

Warum hat meine Ressource keine Arbeit ausgelöst?

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

• Die Quelle der bereitgestellten Dienstverbindung ist ungültig.
• Der Trigger ist nicht konfiguriert, oder es gibt Syntaxfehler im Trigger.
• 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 für Repositoryressourcen nicht verfügbar.

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

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