Definieren von Ressourcen in YAML

  • Artikel

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

Ressourcen in YAML stellen Quellen von Pipelines, Builds, Repositorys, Containern, Paketen und Webhooks dar. Ressourcen bieten Ihnen auch die vollständige Nachverfolgbarkeit der in Ihrer Pipeline verwendeten Dienste, einschließlich der Version, Artefakte, zugeordneten Commits und Arbeitselemente. Wenn Sie eine Ressource definieren, kann sie überall in Ihrer Pipeline genutzt werden. Außerdem können Sie Ihren DevOps-Workflow vollständig automatisieren, indem Sie Triggerereignisse für Ihre Ressourcen abonnieren.

Weitere Informationen finden Sie unter Informationen zu Ressourcen und der YAML-Schemadefinition für Ressourcen.

Schema

resources:
  pipelines: [ pipeline ]  
  builds: [ build ]
  repositories: [ repository ]
  containers: [ container ]
  packages: [ package ]
  webhooks: [ webhook ]

Variables

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

resources.triggeringAlias
resources.triggeringCategory

Diese Werte sind leer, wenn eine Ressource keine Pipelineausführung auslöst. Die Variable Build.Reason muss ResourceTrigger sein, damit diese Werte festgelegt werden.

Definieren einer pipelines-Ressource

Wenn Sie über eine Pipeline verfügen, die Artefakte erzeugt, können Sie die Artefakte nutzen, indem Sie eine pipelines-Ressource definieren. pipelines ist nur für Azure Pipelines eine dedizierte Ressource. Sie können auch Trigger für eine Pipelineressource für Ihre CD-Workflows festlegen.

In Ihrer Ressourcendefinition ist pipeline ein eindeutiger Wert, den Sie verwenden können, um später auf die Pipelineressource zu verweisen. source ist der Name der Pipeline, die ein Artefakt erzeugt. Verwenden Sie die durch pipeline definierte Bezeichnung, um von anderen Teilen der Pipeline aus auf die Pipelineressource zu verweisen, z. B. beim Verwenden von Pipelineressourcenvariablen oder beim Herunterladen von Artefakten.

Eine alternative Möglichkeit zum Herunterladen von Pipelines finden Sie unter den Aufgaben in Pipelineartefakte.

resources:        # types: pipelines | builds | repositories | containers | packages
  pipelines:
  - pipeline: string  # identifier for the resource used in pipeline resource variables
    project: string # project for the source; optional for current project
    source: string  # name of the pipeline that produces an artifact
    version: string  # the pipeline run number to pick the artifact, defaults to latest pipeline successful across all stages; Used only for manual or scheduled triggers
    branch: string  # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
    tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
    trigger:     # triggers aren't enabled by default unless you add trigger section to the resource
      branches:  # branch conditions to filter the events, optional; Defaults to all branches.
        include: [ string ]  # branches to consider the trigger events, optional; Defaults to all branches.
        exclude: [ string ]  # branches to discard the trigger events, optional; Defaults to none.
      tags: [ string ]  # list of tags to evaluate for trigger event, optional
      stages: [ string ] # list of stages to evaluate for trigger event, optional

Wichtig

Wenn Sie einen Ressourcentrigger definieren und die zugehörige Pipelineressource aus demselben Repository (z. B. „self“) stammt wie die aktuelle Pipeline, folgt die Auslösung demselben Branch und Commit, bei dem das Ereignis ausgelöst wird. Wenn die Pipelineressource jedoch aus einem anderen Repository stammt, wird die aktuelle Pipeline auf dem Standardbranch des self-Repositorys ausgelöst.

Auswertung der Artefaktversion

Die Version der Artefakte der Ressourcenpipeline hängt davon ab, wie Ihre Pipeline ausgelöst wird.

Wenn Ihre Pipeline ausgeführt wird, da Sie sie manuell ausgelöst haben oder aufgrund einer geplanten Ausführung, wird die Version der Artefakte durch die Werte der Eigenschaften version, branch und tags definiert.

Angegebene Eigenschaften Artefaktversion
version Die Artefakte aus dem Build mit der angegebenen Ausführungsnummer.
branch Die Artefakte aus dem neuesten Build, der für den angegebenen Branch ausgeführt wurde.
tags-Liste Die Artefakte aus dem neuesten Build mit allen angegebenen Tags
Liste branch und tags Die Artefakte aus dem neuesten Build, der für den angegebenen Branch und mit allen angegebenen Tags ausgeführt wurde.
Keine Die Artefakte aus dem neuesten Build in allen Branches.

Schauen wir uns ein Beispiel an. Angenommen, Ihre Pipeline enthält die folgende Ressourcendefinition.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main      ### This branch input cannot have wild cards. It is used for evaluating default version when pipeline is triggered manually or scheduled.
    tags:               ### These tags are used for resolving default version when the pipeline is triggered manually or scheduled
    - Production        ### Tags are AND'ed
    - PreProduction

Wenn Sie die Ausführung der Pipeline manuell auslösen, entspricht die Version der Artefakte der MyCIAlias-Pipeline der des neuesten Builds, der für den main-Branch durchgeführt wurde und über die Tags Production und PrepProduction verfügt.

Wenn Ihre Pipeline ausgelöst wird, da eine ihrer Ressourcenpipelines abgeschlossen ist, entspricht die Version der Artefakte derjenigen der auslösenden Pipeline. Die Werte der Eigenschaften version, branch und tags werden ignoriert.

Angegebene Trigger Ergebnis
branches Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ressourcenpipeline erfolgreich eine Ausführung auf den include-Branches abgeschlossen hat.
tags Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ressourcenpipeline erfolgreich eine Ausführung abschließt, die mit allen angegebenen Tags markiert ist.
stages Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ressourcenpipeline die angegebene stages erfolgreich ausgeführt hat.
branches, tags und stages Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ausführung der Ressourcenpipeline alle Branch-, Tag- und Phasenbedingungen erfüllt.
trigger: true Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ressourcenpipeline erfolgreich eine Ausführung abgeschlossen hat.
Nichts Es wird keine neue Ausführung der aktuellen Pipeline ausgelöst, wenn die Ressourcenpipeline erfolgreich eine Ausführung abgeschlossen hat.

Schauen wir uns ein Beispiel an. Angenommen, Ihre Pipeline enthält die folgende Ressourcendefinition.

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

Ihre Pipeline wird immer dann ausgeführt, wenn die SmartHotel-CI-Pipeline auf einem der releases-Branches oder auf dem main-Branch ausgeführt wird, mit Verified und Signed gekennzeichnet ist und sowohl die Production- als auch die PreProduction-Phase abgeschlossen hat.

download für Pipelines

Alle Artefakte aus der aktuellen Pipeline und aus allen pipeline-Ressourcen werden automatisch heruntergeladen und zu Beginn eines jeden deployment-Auftrags zur Verfügung gestellt. Sie können dieses Verhalten außer Kraft setzen. Weitere Informationen finden Sie unter Pipelineartefakte. Reguläre „Auftragsartefakte“ werden nicht automatisch heruntergeladen. Verwenden Sie bei Bedarf explizit download.

steps:
- download: [ current | pipeline resource identifier | none ] # disable automatic download if "none"
  artifact: string ## artifact name, optional; downloads all the available artifacts if not specified
  patterns: string # patterns representing files to include; optional

Artefakte aus der pipeline-Ressource werden in den Ordner $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> heruntergeladen.

Variablen der Pipelineressource

In jeder Ausführung sind die Metadaten für eine Pipelineressource für alle Aufträge in Form von vordefinierten Variablen verfügbar. Der <Alias> ist der Bezeichner, den Sie für Ihre Pipelineressource angegeben haben. Die Variablen der Pipelineressource sind nur zur Laufzeit verfügbar.

resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

Weitere Informationen finden Sie unter Metadaten der Pipelineressource als vordefinierte Variablen.

Definieren einer builds-Ressource

Wenn Sie über ein externes CI-Buildsystem verfügen, das Artefakte erzeugt, können Sie Artefakte mit einer builds-Ressource nutzen. Eine builds-Ressource kann ein beliebiges externes CI-System wie Jenkins, TeamCity, CircleCI usw. sein.

resources:        # types: pipelines | builds | repositories | containers | packages
  builds:
  - build: string   # identifier for the build resource
    type: string   # the type of your build service like Jenkins, circleCI etc.
    connection: string   # service connection for your build service.
    source: string   # source definition of the build
    version: string   # the build number to pick the artifact, defaults to Latest successful build
    trigger: boolean    # Triggers aren't enabled by default and should be explicitly set

builds ist eine erweiterbare Kategorie. Sie können eine Erweiterung schreiben, um Artefakte von Ihrem Builddienst zu nutzen und eine neue Art von Dienst als Teil von builds einzuführen. Jenkins ist ein Ressourcentyp in builds.

Wichtig

Trigger werden nur für gehostetes Jenkins unterstützt, bei dem Azure DevOps eine Sichtverbindung mit dem Jenkins-Server hat.

downloadBuild-Aufgabe für Builds

Sie können Artefakte aus der build-Ressource im Rahmen Ihrer Aufträge mithilfe der downloadBuild-Aufgabe verwenden. Basierend auf dem definierten Ressourcentyp build löst diese Aufgabe automatisch die entsprechende Downloadaufgabe für den Dienst während der Laufzeit auf.

Artefakte aus der build-Ressource werden in den Ordner $(PIPELINE.WORKSPACE)/<build-identifier>/ heruntergeladen.

Wichtig

build-Ressourcenartefakte werden nicht automatisch in Ihren Aufträgen/Bereitstellungsaufträgen heruntergeladen. Sie müssen explizit die Aufgabe downloadBuild zur Verwendung der Artefakte hinzufügen.

- downloadBuild: string # identifier for the resource from which to download artifacts
  artifact: string # artifact to download; if left blank, downloads all artifacts associated with the resource provided
  patterns: string | [ string ] # a minimatch path or list of [minimatch paths](tasks/file-matching-patterns.md) to download; if blank, the entire artifact is downloaded

Definieren einer repositories-Ressource

Wenn Ihre Pipeline über Vorlagen in einem anderen Repository verfügt, oder Sie das Auschecken mehrerer Repositorys mit einem Repository verwenden möchten, das eine Dienstverbindung erfordert, müssen Sie das System über dieses Repository informieren. Mit dem repository-Schlüsselwort können Sie ein externes Repository angeben.

resources:
    repositories:
    - repository: string # Required as first property. Alias for the repository.
      endpoint: string # ID of the service endpoint connecting to this repository.
      trigger: none | trigger | [ string ] # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos).
      name: string # repository name (format depends on 'type'; does not accept variables).
      ref: string # ref name to checkout; defaults to 'refs/heads/main'. The branch checked out by default whenever the resource trigger fires.
      type: string # Type of repository: git, github, githubenterprise, and bitbucket.

Typ

Pipelines unterstützen die folgenden Werte für den Repositorytyp: git, github, githubenterprise und bitbucket. Der git-Typ bezieht sich auf Azure Repos Git-Repositorys.

Typ angegeben Ergebnis Beispiel
type: git Der name-Wert verweist auf ein anderes Repository im selben Projekt. name: otherRepo: Wenn Sie auf ein Repository in einem anderen Projekt innerhalb derselben Organisation verweisen möchten, stellen Sie dem Namen den Namen dieses Projekts voran. z. B. name: OtherProject/otherRepo.
type: github Der name-Wert ist der vollständige Name des GitHub-Repositorys und enthält den Benutzer oder die Organisation. name: Microsoft/vscode
type: githubenterprise Der name-Wert ist der vollständige Name des GitHub Enterprise-Repositorys und enthält den Benutzer oder die Organisation. name: Microsoft/vscode
type: bitbucket Der name-Wert ist der vollständige Name des Bitbucket Cloud-Repositorys und enthält den Benutzer oder die Organisation. name: MyBitbucket/vscode

GitHub Enterprise-Repositorys benötigen zur Autorisierung eine GitHub Enterprise-Dienstverbindung.

Bitbucket Cloud-Repositorys benötigen eine Bitbucket Cloud-Dienstverbindung zur Autorisierung.

Variables

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

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

Variablen

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

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

Verwenden von checkout zum Nutzen des Repositorys

Verwenden Sie das Schlüsselwort checkout, um Ihre Repositorys zu verwenden, die als Teil der Ressource repository definiert sind.

Schema

steps:
- checkout: string # Required as first property. Configures checkout for the specified repository.
  clean: string # If true, run git clean -ffdx followed by git reset --hard HEAD before fetching.
  fetchDepth: string # Depth of Git graph to fetch.
  fetchTags: string # Set to 'true' to sync tags when fetching the repo, or 'false' to not sync tags. See remarks for the default behavior.
  lfs: string # Set to 'true' to download Git-LFS files. Default is not to download them.
  persistCredentials: string # Set to 'true' to leave the OAuth token in the Git config after the initial fetch. The default is not to leave it.
  submodules: string # Set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules. Default is not to fetch submodules.
  path: string # Where to put the repository. The default is $(Build.SourcesDirectory).
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

Repositorys aus der repository-Ressource werden nicht automatisch in Ihren Aufträgen synchronisiert. Verwenden Sie checkout, um Ihre Repositorys als Teil Ihrer Aufträge abzurufen.

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

Definieren einer containers-Ressource

Wenn Sie ein Containerimage als Teil Ihrer CI/CD-Pipeline (Continuous Integration/Continuous Delivery) verwenden möchten, können Sie dies mithilfe von containers erreichen. Eine Containerressource kann eine öffentliche oder private Docker-Registrierung oder eine Azure Container Registry-Instanz sein.

Wenn Sie als Teil Ihrer Pipeline Images aus der Docker-Registrierung verwenden möchten, können Sie eine generische Containerressource definieren (kein type-Schlüsselwort erforderlich).

resources:
  containers:
  - container: string  # identifier (A-Z, a-z, 0-9, and underscore)
    image: string  # container image name
    options: string  # arguments to pass to container at startup
    endpoint: string  # reference to a service connection for the private registry
    env: { string: string }  # list of environment variables to add
    ports: [ string ] # ports to expose on the container
    volumes: [ string ] # volumes to mount on the container
    mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
    mountReadOnly:  # volumes to mount read-only - all default to false
      externals: boolean  # components required to talk to the agent
      tasks: boolean  # tasks required by the job
      tools: boolean  # installable tools like Python and Ruby
      work: boolean # the work directory

Sie können eine generische Containerressource als Image verwenden, das als Teil Ihres Auftrags genutzt wird, oder sie kann auch für Containeraufträge verwendet werden. Wenn Ihre Pipeline die Unterstützung eines oder mehrerer Dienste erfordert, sollten Sie Dienstcontainer erstellen und mit diesen eine Verbindung herstellen. Sie können Volumes verwenden, um Daten zwischen Diensten freizugeben.

Sie können einen erstklassigen Containerressourcentyp für Azure Container Registry (ACR) verwenden, um Ihre ACR-Images zu nutzen. Dieser Ressourcentyp kann als Teil Ihrer Aufträge und zum Aktivieren automatischer Pipelinetrigger verwendet werden. Sie benötigen die Berechtigungen Mitwirkender oder Besitzer für ACR, um automatische Pipelinetrigger zu verwenden. Weitere Informationen finden Sie unter Azure Container Registry: Rollen und Berechtigungen.

resources:          # types: pipelines | repositories | containers | builds | packages
  containers:
  - container: string # identifier for the container resource      
    type: string # type of the registry like ACR, GCR etc. 
    azureSubscription: string # Azure subscription (ARM service connection) for container registry;
    resourceGroup: string # resource group for your ACR
    registry: string # registry for container images
    repository: string # name of the container image repository in ACR
    trigger: # Triggers aren't enabled by default and need to be set explicitly
      enabled: boolean # set to 'true' to trigger on all image tags if 'tags' is unset.
      tags:
        include: [ string ]  # image tags to consider the trigger events, optional; defaults to any new tag
        exclude: [ string ]  # image tags on discard the trigger events, optional; defaults to none

Hinweis

Die Syntax, die zum Aktivieren von Containertriggern für alle Imagetags (enabled: 'true') verwendet wird, unterscheidet sich von der Syntax, die für andere Ressourcentrigger verwendet wird. Achten Sie genau darauf, die richtige Syntax für eine bestimmte Ressource zu verwenden.

Hinweis

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

Containerressourcenvariablen

Sobald Sie einen Container als Ressource definieren, werden Containerimage-Metadaten in Form von 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.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Die Standortvariable gilt nur für den ACR-Typ von Containerressourcen.

Definieren einer packages-Ressource

Sie können NuGet- und npm-GitHub-Pakete als Ressource in YAML-Pipelines nutzen.

Wenn Sie package-Ressourcen angeben, legen Sie das Paket als NuGet oder npm fest. Sie können auch automatische Pipelinetrigger aktivieren, wenn eine neue Paketversion veröffentlicht wird.

Um GitHub-Pakete zu verwenden, verwenden Sie eine Authentifizierung auf der Basis von persönlichen Zugriffstoken (Personal Access Token, PAT) und erstellen eine GitHub-Dienstverbindung, die PATs verwendet.

Standardmäßig werden Pakete nicht automatisch in Aufträge heruntergeladen. Verwenden Sie zum Herunterladen getPackage.

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConnectionName # GitHub service connection with the PAT type
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.1 # Version of the package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Definieren einer webhooks-Ressource

Hinweis

Webhooks wurden in Azure DevOps Server 2020.1 veröffentlicht.

Mit anderen Ressourcen (wie Pipelines, Containern, Builds und Paketen) können Sie Artefakte nutzen und automatische Trigger aktivieren. Sie können Ihren Bereitstellungsprozess jedoch nicht auf der Grundlage anderer externer Ereignisse oder Dienste automatisieren. Mit der webhooks-Ressource können Sie Ihre Pipeline in jeden externen Dienst integrieren und den Workflow automatisieren. Sie können alle externen Ereignisse über ihre Webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory usw.) abonnieren und Ihre Pipelines auslösen.

Führen Sie die folgenden Schritte aus, um die Webhooktrigger zu konfigurieren.

  1. Richten Sie einen Webhook für Ihren externen Dienst ein. Wenn Sie Ihren Webhook erstellen, müssen Sie die folgenden Informationen angeben:

    • Anforderungs-URL

      https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview

    • Geheimnis – Optional Wenn Sie Ihre JSON-Nutzdaten schützen müssen, geben Sie den Wert für das Geheimnis an.

  2. Erstellen Sie eine neue Dienstverbindung vom Typ „Eingehender Webhook“. Diese Verbindung ist ein neu eingeführter Dienstverbindungstyp, mit dem Sie die folgenden wichtigen Informationen definieren können:

    • Webhookname: Der Name des Webhooks sollte dem in Ihrem externen Dienst erstellten Webhook entsprechen.
    • HTTP-Header: Der Name des HTTP-Headers in der Anforderung, der den HMAC-SHA1-Hashwert der Nutzdaten zur Überprüfung der Anforderung enthält. Für GitHub lautet der Header der Anforderung z. B. „X-Hub-Signature“.
    • Geheimnis: Das Geheimnis wird verwendet, um den HMAC-SHA1-Hash der Nutzdaten zu überprüfen, der zur Überprüfung der eingehenden Anforderung verwendet wird (optional). Wenn Sie beim Erstellen Ihres Webhooks ein Geheimnis verwendet haben, müssen Sie denselben geheimen Schlüssel angeben.

    Incoming Webhook Service connection

  3. Ein neuer Ressourcentyp namens webhooks wird in YAML-Pipelines eingeführt. Um ein Webhookereignis zu abonnieren, definieren Sie eine Webhookressource in Ihrer Pipeline, und verweisen sie auf die eingehende Webhookdienstverbindung. 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. Verbrauchen Sie die Nutzdaten in Form von Variablen in Ihren Aufträgen.

  4. Immer, wenn die eingehende Webhookdienstverbindung ein Webhookereignis empfängt, wird eine neue Ausführung für alle Pipelines ausgelöst, die das Webhookereignis abonniert haben. Sie können die JSON-Nutzdaten in Ihren Aufträgen mithilfe des Formats ${{ parameters.<WebhookAlias>.<JSONPath>}} nutzen.

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias           ### Webhook alias
      connection: IncomingWebhookConnection    ### Incoming webhook service connection
      filters:                                 ### List of JSON parameters to filter; Parameters are AND'ed
        - path: JSONParameterPath              ### JSON path in the payload
          value: JSONParameterExpectedValue    ### Expected value in the path provided

Webhooks automatisieren Ihren Workflow auf der Grundlage eines externen Webhookereignisses, das nicht von erstklassigen Ressourcen wie Pipelines, Builds, Container und Pakete unterstützt wird. Auch für lokale Dienste, bei denen Azure DevOps keinen Einblick in den Prozess hat, können Sie Webhooks für den Dienst konfigurieren, um Ihre Pipelines automatisch auszulösen.

Manuelle Versionsauswahl für Ressourcen im Dialogfeld zum Erstellen einer Ausführung

Wenn Sie eine CD-YAML-Pipeline manuell auslösen, werten wir automatisch die Standardversion für die in der Pipeline definierten Ressourcen basierend auf den angegebenen Eingaben aus. Sie können jedoch eine andere Version aus der Versionsauswahl der Ressource auswählen, wenn Sie eine Ausführung erstellen.

  1. Wählen Sie im Bereich Ausführung erstellen die Option Ressourcen aus. Es wird eine Liste der in dieser Pipeline verbrauchten Ressourcen angezeigt.

  2. Wählen Sie eine Ressource und dann eine bestimmte Version aus der Liste der verfügbaren Versionen aus. Die Ressourcenversionsauswahl wird für Pipeline-, Build-, Repository-, Container- und Paketressourcen unterstützt.

    Pipeline Version Picker

Für Pipelineressourcen werden alle verfügbaren Ausführungen aus allen Branches angezeigt. Suchen Sie sie anhand der Pipelinenummer oder des Branchs. Und wählen Sie eine Ausführung aus, die erfolgreich, fehlerhaft oder in Bearbeitung ist. Diese Flexibilität gewährleistet, dass Sie Ihre CD-Pipeline ausführen können, wenn Sie sicher sind, dass sie alle erforderlichen Artefakte erzeugt hat. Sie müssen nicht warten, bis die CI-Ausführung abgeschlossen oder erneut ausgeführt wird, da ein nicht verwandter Phasenfehler in der CI-Ausführung aufgetreten ist. Wir berücksichtigen jedoch nur erfolgreich ausgeführte CI-Ausführungen, wenn wir die Standardversion für geplante Trigger auswerten oder wenn Sie keine manuelle Versionsauswahl verwenden.

Für Ressourcen, von denen Sie keine verfügbaren Versionen abrufen können, z. B. GitHub-Pakete, zeigen wir ein Textfeld als Teil der Versionsauswahl an, sodass Sie die Version angeben können, die für die Ausführung gewählt werden soll.

Autorisieren einer YAML-Pipeline

Ressourcen müssen vor der Verwendung autorisiert werden. Ein Ressourcenbesitzer kontrolliert die Benutzer und Pipelines, die auf diese Ressource zugreifen können. Die Pipeline muss für die Verwendung der Ressource autorisiert sein. Sehen Sie sich die folgenden Möglichkeiten an, wie Sie eine YAML-Pipeline autorisieren können.

  • Wechseln Sie zur Verwaltungsoberfläche der Ressource. Variablengruppen und sichere Dateien werden beispielsweise auf der Seite Bibliothek unter Pipelines verwaltet. Agentpools und Dienstverbindungen werden in Projekteinstellungen verwaltet. Hier können Sie alle Pipelines für den Zugriff auf diese Ressource autorisieren. Diese Autorisierung ist praktisch, wenn Sie den Zugriff auf eine Ressource – z. B. Testressourcen – nicht einschränken müssen.

  • Wenn Sie eine Pipeline zum ersten Mal erstellen, werden alle Ressourcen, auf die in der YAML-Datei verwiesen wird, automatisch für die Verwendung durch die Pipeline autorisiert, wenn Sie Mitglied der Rolle Benutzer für diese Ressource sind. So werden Ressourcen, auf die in der YAML-Datei verwiesen wird, wenn Sie eine Pipeline erstellen, automatisch autorisiert.

  • Wenn Sie Änderungen an der YAML-Datei vornehmen und Ressourcen hinzufügen, tritt beim Build ein Fehler auf, der dem folgenden Fehler ähnelt: Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.

    In diesem Fall wird eine Option zum Autorisieren der Ressourcen für den fehlerhaften Build angezeigt. Wenn Sie ein Mitglied der Rolle Benutzer für die Ressource sind, können Sie diese Option auswählen. Sobald die Ressourcen autorisiert sind, können Sie einen neuen Build starten.

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

Festlegen von Genehmigungsüberprüfungen für Ressourcen

Sie können manuell steuern, wann eine Ressource mit Genehmigungsüberprüfungen und Vorlagen ausgeführt wird. Mit der erforderlichen Überprüfung zur Vorlagengenehmigung können Sie anfordern, dass jede Pipeline, die eine Ressource oder Umgebung verwendet, auch von einer bestimmten YAML-Vorlage ausgeht. Das Festlegen einer erforderlichen Vorlagengenehmigung erhöht die Sicherheit. Stellen Sie sicher, dass Ihre Ressource nur unter bestimmten Bedingungen mit einer Vorlage verwendet wird. Erfahren Sie mehr darüber, wie Sie die Pipelinesicherheit mit Vorlagen und Ressourcen verbessern.

Nachverfolgbarkeit

Wir bieten vollständige Nachverfolgbarkeit für jede Ressource, die auf Pipelineebene oder der Ebene des Bereitstellungsauftrags genutzt wird.

Nachverfolgbarkeit von Pipelines

Für jede Pipelineausführung zeigen wir die folgenden Informationen an.

  • Die Ressource, die die Pipeline ausgelöst hat, wenn sie durch eine Ressource ausgelöst wurde.

    Resource trigger in a pipeline

  • Version der Ressource und der verbrauchten Artefakte.

    Consumed artifacts in pipeline run

  • Den jeweiligen Ressourcen zugeordnete Commits.

    Commits in pipeline run

  • 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 folgende Ansicht enthält die im Rahmen der Bereitstellungsaufträge und ihrer zugeordneten Commits und Arbeitselemente verbrauchten Ressourcen.

Commits in environment

Anzeigen zugehöriger CD-Pipelineinformationen in CI-Pipelines

Um die End-to-End-Nachverfolgbarkeit zu ermöglichen, können Sie nachverfolgen, welche CD-Pipelines eine angegebene CI-Pipeline nutzen. Sie können die Liste der CD-YAML-Pipelineausführungen anzeigen, bei denen eine CI-Pipelineausführung über die pipeline-Ressource genutzt wird. Wenn Ihre CI-Pipeline von anderen Pipelines genutzt wird, wird die Registerkarte „Zugeordnete Pipelines“ in der Ausführungsansicht angezeigt. Hier finden Sie alle Pipelineausführungen, die Ihre Pipeline und Artefakte nutzen.

CD pipelines information in CI pipeline

Unterstützung und Nachverfolgbarkeit bei YAML-Ressourcentriggerproblemen

Es kann verwirrend sein, wenn Pipelinetrigger nicht ausgeführt werden können. Wir haben auf der Pipelinedefinitionsseite ein neues Element mit dem Namen Triggerprobleme hinzugefügt, unter dem Sie erfahren können, warum Trigger nicht ausgeführt werden. Öffnen Sie den Pipelineverlauf, um auf diese Seite zuzugreifen. Triggerprobleme ist nur für Nicht-Repositoryressourcen verfügbar.

Select Trigger Issues from the navigation.

Ressourcentrigger können aus folgenden Gründen nicht ausgeführt werden.

  • Wenn die Quelle der bereitgestellten Dienstverbindung ungültig ist oder der Trigger Syntaxfehler enthält, wird der Trigger nicht konfiguriert, was zu einem Fehler führt.

  • Wenn die Triggerbedingungen nicht erfüllt sind, wird der Trigger nicht ausgeführt. Es wird eine Warnung angezeigt, damit Sie verstehen können, warum die Bedingungen nicht erfüllt werden.

    Trigger issues supportability

Nächste Schritte

Hinzufügen und Verwenden von Variablengruppen

Häufig gestellte Fragen

Warum sollte ich die resources von Pipelines anstelle der download-Tastenkombination 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 Artefakte in Buildaufträgen herunterladen oder das Downloadverhalten in Bereitstellungsaufträgen mit download außer Kraft setzen. Weitere Informationen finden Sie unter steps.download.

Warum sollte ich resources anstelle der Aufgabe „Pipelineartefakte herunterladen“ verwenden?

Wenn Sie die Aufgabe Pipelineartefakte herunterladen direkt verwenden, entgehen Ihnen Nachverfolgbarkeit und Trigger. Manchmal ist es sinnvoll, die Aufgabe „Pipelineartefakte herunterladen“ direkt zu verwenden. Sie könnten z. B. eine Skriptaufgabe in einer anderen Vorlage gespeichert haben und die Skriptaufgabe erfordert das Herunterladen von Artefakten aus einem Build. Oder Sie wissen möglicherweise nicht, ob jemand, der eine Vorlage verwendet, eine Pipelineressource hinzufügen möchte. 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?

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

  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. Wählen Sie den Namespace, das Repository, die Version und den Quellalias aus.

    Add a Docker Hub artifact.

  3. Wählen Sie den Trigger aus, und schalten Sie den Continuous Deployment-Trigger auf Aktivieren um. Sie erstellen jedes Mal eine Version, wenn ein Docker-Push für das ausgewählte Repository auftritt.

  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. Ersetzen Sie hub-user, repo-name und tag durch Ihre eigenen Werte.

    Add Docker login and Bash tasks.

Wie kann ich 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. Wenn Sie Ihre Pipeline ausführen, wird der Webhook 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.

    1. Öffnen Sie Ihre Pipeline.
    2. Wählen Sie Bearbeiten aus.
    3. Wählen Sie das Menü „Weitere Aktionen“ Select more actions menu aus.
    4. Wählen Sie Trigger>YAML>Quellen abrufen aus.
    5. Wechseln Sie zu Standardbranch für manuelle und geplante Builds, um Ihren Featurebranch zu aktualisieren.
    6. Wählen Sie Save & queue (Speichern und in Warteschlange einreihen) aus.
    7. 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.