Definieren von Ressourcen in YAML

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 Ereignisse für Ihre Ressourcen abonnieren.

Weitere Informationen finden Sie unter Informationen zu Ressourcen.

Schema

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

Variablen

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 festgelegt sein, damit diese Werte festgelegt werden ResourceTrigger können.

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 eine dedizierte Ressource nur für Azure Pipelines. Sie können auch Trigger für eine Pipelineressource für Ihre CD-Workflows festlegen.

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

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

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 dessen Pipelineressource aus demselben Repository (z. B. selbst) wie die aktuelle Pipeline stammt, folgt die Triggerung demselben Branch und Commit, für den das Ereignis ausgelöst wird. Wenn die Pipelineressource jedoch aus einem anderen Repository stammt, wird die aktuelle Pipeline auf der Standardbranch des Selbstrepositorys 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, weil Sie sie manuell ausgelöst haben oder aufgrund einer geplanten Ausführung, wird die Version der Artefaktversion durch die Werte der versionEigenschaften , branchund 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
branch und tags auflisten Die Artefakte aus dem neuesten Build, der für den angegebenen Branch ausgeführt wurde und über alle angegebenen Tags verfügt
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 Pipeline für die Ausführung manuell auslösen, ist die Version der Artefakte der MyCIAlias Pipeline eine der neuesten Builds, die für den main Branch ausgeführt wurden und über die Production Tags und PrepProduction verfügt.

Wenn Ihre Pipeline ausgelöst wird, weil eine ihrer Ressourcenpipelines abgeschlossen ist, ist die Version der Artefakte diejenige der auslösenden Pipeline. Die Werte der versionEigenschaften , branchund tags werden ignoriert.

Angegebene Trigger Ergebnis
branches Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ressourcenpipeline eine Ausführung für die include Branches erfolgreich abgeschlossen hat.
tags Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ressourcenpipeline eine Ausführung erfolgreich abgeschlossen hat, die mit allen angegebenen Tags markiert ist.
stages Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ressourcenpipeline den angegebenen erfolgreich ausgeführt hat. stages
branches, tags und stages Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ausführung der Ressourcenpipeline alle Branch-, Tags- und Phasenbedingungen erfüllt.
trigger: true Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ressourcenpipeline eine Ausführung erfolgreich abgeschlossen hat.
Nichts Es wird keine neue Ausführung der aktuellen Pipeline ausgelöst, wenn die Ressourcenpipeline eine Ausführung erfolgreich 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 Pipelines auf einem der releases Branches oder auf dem main Branch ausgeführt werden, mit Verified und Signedmarkiert ist und sowohl die Production Phasen als PreProduction auch abgeschlossen hat.

download für Pipelines

Alle Artefakte aus der aktuellen Pipeline und aus allen pipeline Ressourcen werden automatisch heruntergeladen und zu Beginn jedes deployment Auftrags zur Verfügung gestellt. Sie können dieses Verhalten überschreiben. Weitere Informationen finden Sie unter Pipelineartefakte. Reguläre "Auftragsartefakte" werden nicht automatisch heruntergeladen. Verwenden Sie download bei Bedarf explizit.

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 $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> Ordner heruntergeladen.

Pipelineressourcenvariablen

In jeder Ausführung stehen die Metadaten für eine Pipelineressource für alle Aufträge in Form vordefinierter Variablen zur Verfügung. Der <Alias> ist der Bezeichner, den Sie für Ihre Pipelineressource angegeben haben. Pipelineressourcenvariablen 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 Pipelineressourcenmetadaten 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 beliebige externe CI-Systeme 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 aus Ihrem Builddienst zu nutzen und einen neuen Diensttyp als Teil von buildseinzuführen. Jenkins ist ein Ressourcentyp in builds.

Wichtig

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

downloadBuild Aufgabe für Builds

Sie können Artefakte aus der build Ressource als Teil Ihrer Aufträge verwenden, indem Sie die downloadBuild Aufgabe verwenden. Basierend auf dem definierten build Ressourcentyp wird dieser Task während der Laufzeit automatisch in den entsprechenden Downloadtask für den Dienst aufgelöst.

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

Wichtig

build Ressourcenartefakte werden nicht automatisch in Ihre aufträge/deploy-jobs heruntergeladen. Sie müssen die downloadBuild Aufgabe zum Verbrauch der Artefakte explizit 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 Vorlagen in einem anderen Repository enthält oder Wenn 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 repository der Schlüsselwort (keyword) 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.

type

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

Typ angegeben Ergebnis Beispiel
type: git Der name Wert bezieht sich auf ein anderes Repository im selben Projekt. name: otherRepoUm auf ein Repository in einem anderen Projekt innerhalb desselben organization zu verweisen, setzen 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 organization. name: Microsoft/vscode
type: githubenterprise der name Wert ist der vollständige Name des GitHub Enterprise-Repositorys und enthält den Benutzer oder organization. name: Microsoft/vscode
type: bitbucket Der name Wert ist der vollständige Name des Bitbucket Cloud-Repositorys und enthält den Benutzer oder organization. name: MyBitbucket/vscode

GitHub Enterprise-Repositorys erfordern eine GitHub Enterprise-Dienstverbindung für die Autorisierung.

Bitbucket Cloud-Repositorys erfordern eine Bitbucket Cloud-Dienstverbindung für die Autorisierung.

Verwenden von checkout zum Verwenden des Repositorys

Verwenden Sie checkout Schlüsselwort (keyword), um Ihre als Teil der Ressource definierten Repositorys repository zu nutzen.

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 root directory is $(Pipeline.Workspace).
  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 in Ihren Aufträgen nicht automatisch synchronisiert. Verwenden Sie checkout , um Ihre Repositorys als Teil Ihrer Aufträge abzurufen.

Weitere Informationen finden Sie unter Überprüfen mehrerer Repositorys in Ihrer Pipeline.

Definieren einer containers Ressource

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

Wenn Sie Images aus der Docker-Registrierung als Teil Ihrer Pipeline nutzen müssen, können Sie eine generische Containerressource definieren (nicht type Schlüsselwort (keyword) 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 verwendet 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 eine Verbindung mit diesen herstellen. Sie können Volumes verwenden, um Daten zwischen Diensten gemeinsam zu nutzen.

Sie können einen Containerressourcentyp der ersten Klasse für Azure Container Registry (ACR) verwenden, um Ihre ACR-Images zu nutzen. Dieser Ressourcentyp kann als Teil Ihrer Aufträge und auch zum Aktivieren automatischer Pipelinetrigger verwendet werden. Sie benötigen die Berechtigungen Mitwirkender oder Besitzer , damit ACR automatische Pipelinetrigger verwenden kann. 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 darauf, die richtige Syntax für eine bestimmte Ressource zu verwenden.

Containerressourcenvariablen

Nachdem Sie einen Container als Ressource definiert haben, werden Containerimagemetadaten in Form von Variablen an die Pipeline übergeben. Informationen wie Image-, Registrierungs- und Verbindungsdetails sind für alle Aufträge zugänglich, die in Ihren Containerbereitstellungsaufgaben verwendet werden sollen.

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 ACR den Typ von Containerressourcen.

Definieren einer packages Ressource

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

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

Um GitHub-Pakete zu verwenden, verwenden Sie die auf persönlichen Zugriffstoken (PAT) basierende Authentifizierung, und erstellen Sie eine GitHub-Dienstverbindung, die PATs verwendet.

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

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 (z. B. Pipelines, Containern, Build und Paketen) können Sie Artefakte nutzen und automatisierte Trigger aktivieren. Sie können Ihren Bereitstellungsprozess jedoch nicht basierend auf anderen externen Ereignissen oder Diensten automatisieren. Mit webhooks der Ressource können Sie Ihre Pipeline in einen beliebigen externen Dienst integrieren und den Workflow automatisieren. Sie können alle externen Ereignisse über die zugehörigen 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-Nutzlast schützen müssen, geben Sie den Wert Geheimnis an.
  2. Erstellen Sie eine neue "Eingehende Webhook"-Dienstverbindung. Diese Verbindung ist ein neu eingeführter Dienstverbindungstyp, mit dem Sie die folgenden wichtigen Informationen definieren können:

    • Webhookname: Der Name des Webhooks sollte mit dem in Ihrem externen Dienst erstellten Webhook übereinstimmen.
    • HTTP-Header : Der Name des HTTP-Headers in der Anforderung, der den HMAC-SHA1-Hashwert der Nutzlast für die Anforderungsüberprüfung enthält. Für GitHub lautet der Anforderungsheader beispielsweise "X-Hub-Signature".
    • Geheimnis : Das Geheimnis wird verwendet, um den HMAC-SHA1-Hash der Nutzlast zu überprüfen, der für die Ü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.

    Eingehende Webhookdienstverbindung

  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 basierend auf den JSON-Nutzlastdaten definieren, um die Trigger für jede Pipeline anzupassen. Nutzen Sie die Nutzlastdaten in Form von Variablen in Ihren Aufträgen.

  4. 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-Nutzlastdaten in Ihren Aufträgen im Format verwenden. ${{ parameters.<WebhookAlias>.<JSONPath>}}

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 basierend auf einem externen Webhookereignis, das von Erstklassigen Ressourcen nicht unterstützt wird. Ressourcen wie Pipelines, Builds, Container und Pakete. 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.

Manuelle Versionsauswahl für Ressourcen im Dialogfeld "Ausführung erstellen"

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

  1. Wählen Sie im Bereich Ausführung erstellendie Option Ressourcen aus. Sie sehen eine Liste der Ressourcen, die in dieser Pipeline verbraucht werden.

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

    Pipelineversionsauswahl

Für Pipelineressourcen werden alle verfügbaren Ausführungen in allen Branches angezeigt. Suchen Sie sie basierend auf der Pipelinenummer oder dem Branch. Wählen Sie eine Ausführung aus, 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 sie alle benötigten Artefakte erzeugt hat. Sie müssen nicht warten, bis die CI-Ausführung abgeschlossen oder erneut ausgeführt wurde, weil ein nicht verwandter Phasenfehler in der CI-Ausführung aufgetreten ist. Wir betrachten jedoch nur erfolgreich abgeschlossene CI-Ausführungen, wenn wir die Standardversion für geplante Trigger auswerten oder wenn Sie keine manuelle Versionsauswahl verwenden.

Für Ressourcen, für die Sie keine verfügbaren Versionen abrufen können, z. B. GitHub-Pakete, wird ein Textfeld als Teil der Versionsauswahl angezeigt, damit Sie die Version für die Ausführung angeben können.

Autorisieren einer YAML-Pipeline

Ressourcen müssen autorisiert werden, bevor sie verwendet werden können. Ein Ressourcenbesitzer steuert 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 zum Autorisieren einer YAML-Pipeline an.

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

  • Wenn Sie zum ersten Mal 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 Mitglied der Rolle Benutzer für diese Ressource sind. Ressourcen, auf die in der YAML-Datei beim Erstellen einer Pipeline verwiesen wird, werden also automatisch autorisiert.

  • Wenn Sie Änderungen an der YAML-Datei vornehmen und Ressourcen hinzufügen, schlägt der Buildfehler mit einem Fehler ähnlich dem folgenden Fehler fehl: 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 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.

  • Vergewissern Sie sich, dass die Sicherheitsrollen des Agentpools für Ihr Projekt richtig sind.

Festlegen von Genehmigungsprüfungen für Ressourcen

Sie können manuell steuern, wann eine Ressource mit Genehmigungsprüfungen und Vorlagen ausgeführt wird. Mit der erforderlichen Vorlagengenehmigungsprüfung können Sie jede Pipeline mit einer Ressource oder Umgebung anfordern, die sich auch aus einer bestimmten YAML-Vorlage erweitert. 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 Rückverfolgbarkeit für alle Ressourcen, die auf Pipeline- oder Bereitstellungsauftragsebene verbraucht werden.

Nachverfolgbarkeit der Pipeline

Für jede Pipelineausführung werden die folgenden Informationen angezeigt.

  • Die Ressource, die die Pipeline ausgelöst hat, wenn sie von einer Ressource ausgelöst wird.

    Ressourcentrigger in einer Pipeline

  • Version der Ressource und der verwendeten Artefakte.

    Verbrauchte Artefakte in der Pipelineausführung

  • Commits, die jeder Ressource zugeordnet sind.

    Commits in der Pipelineausführung

  • Arbeitselemente, die jeder Ressource zugeordnet sind.

Nachverfolgbarkeit von Umgebungen

Wenn eine Pipeline in einer Umgebung bereitgestellt wird, wird eine Liste der Ressourcen angezeigt, die genutzt werden. Die folgende Ansicht enthält Ressourcen, die als Teil der Bereitstellungsaufträge verwendet werden, und die zugehörigen Commits und Arbeitselemente.

Commits in der Umgebung

Anzeigen zugeordneter CD-Pipelineinformationen in CI-Pipelines

Um die End-to-End-Rückverfolgbarkeit zu gewährleisten, können Sie nachverfolgen, welche CD-Pipelines eine gebende CI-Pipeline verbrauchen. Sie können die Liste der CD-YAML-Pipelines sehen, die ausgeführt werden, bei denen eine CI-Pipelineausführung über die pipeline Ressource genutzt wird. Wenn andere Pipelines Ihre CI-Pipeline nutzen, wird in der Ausführungsansicht die Registerkarte "Zugeordnete Pipelines" angezeigt. Hier finden Sie alle Pipelineausführungen, die Ihre Pipeline nutzen, und Artefakte daraus.

Informationen zu CD-Pipelines in der CI-Pipeline

YaML-Ressourcentriggerprobleme: Unterstützung und Rückverfolgbarkeit

Es kann verwirrend sein, wenn Pipelinetrigger nicht ausgeführt werden können. Wir haben ein neues Menüelement auf der Pipelinedefinitionsseite namens Trigger Issues hinzugefügt, auf dem Sie erfahren können, warum Trigger nicht ausgeführt werden. Um auf diese Seite zuzugreifen, öffnen Sie Ihren Pipelineverlauf. Triggerprobleme sind nur für Nicht-Repository-Ressourcen verfügbar.

Wählen Sie im Navigationsbereich Die Option Probleme auslösen aus.

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

  • Wenn die Quelle der bereitgestellten Dienstverbindung ungültig ist oder syntaxfehler im Trigger vorhanden sind, wird der Trigger nicht konfiguriert, was zu einem Fehler führt.

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

    Unterstützung von Problemen auslösen

Nächste Schritte

Häufig gestellte Fragen

Warum sollte ich Pipelines resources anstelle der download Verknüpfung verwenden?

Die Verwendung einer pipelines Ressource ist eine Möglichkeit, Artefakte aus einer CI-Pipeline zu nutzen und automatisierte Trigger zu konfigurieren. Eine Ressource bietet Ihnen einen vollständigen Einblick in den Prozess, indem sie die verwendete Version, Artefakte, Commits und Arbeitselemente anzeigt. Wenn Sie eine Pipelineressource definieren, werden die zugehörigen Artefakte automatisch in Bereitstellungsaufträge heruntergeladen.

Sie können die Artefakte in Buildaufträgen herunterladen oder das Downloadverhalten in Bereitstellungsaufträgen mit downloadüberschreiben. Der download Task verwendet intern die Aufgabe Pipelineartefakte herunterladen.

Warum sollte ich anstelle der Aufgabe Pipelineartefakte herunterladen verwenden resources ?

Wenn Sie die Aufgabe Pipelineartefakte herunterladen direkt verwenden, fehlen die Nachverfolgbarkeit und Trigger. Manchmal ist es sinnvoll, die Aufgabe Pipelineartefakte herunterladen direkt zu verwenden. Beispielsweise kann ein Skripttask in einer anderen Vorlage gespeichert sein, und für die Skriptaufgabe müssen Artefakte aus einem Build heruntergeladen werden. 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 einen Task 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.

    Fügen Sie ein Docker Hub Artefakt hinzu.

  3. Wählen Sie den Trigger aus, und schalten Sie den Trigger für continuous deployment auf Aktivieren um. Sie erstellen jedes Mal ein Release, wenn ein Docker-Push in das ausgewählte Repository erfolgt.

  4. Erstellen Sie eine neue Phase und einen neuen Auftrag. Fügen Sie zwei Aufgaben hinzu: Docker-Anmeldung und Bash:

  • Der Docker-Task verfügt über die login Aktion und meldet Sie bei Docker Hub an.

  • Der Bash-Task führt aus docker pull <hub-user>/<repo-name>[:<tag>]. Ersetzen Sie hub-user, repo-name und tag durch Ihre eigenen Werte.

    Fügen Sie Docker-Anmelde- und Bash-Tasks hinzu.

Wie kann ich Webhooks überprüfen und behandeln?

  1. Erstellen Sie eine Dienstverbindung.

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

    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 organization erstellt.

  4. Führen Sie einen POST API-Aufruf mit gültigem JSON-Code im Text für aus https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Wenn Sie eine Codeantwort mit 200 status erhalten, ist Ihr Webhook bereit für die Nutzung durch Ihre Pipeline. Wenn Sie eine 500 status Codeantwort 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 Auswählen des Menüs " aus.
    4. Wählen Sie Triggers>YAML>Get Sources aus.
    5. Wechseln Sie zu Standardbranch für manuelle und geplante Builds, um Ihre Featurebranch zu aktualisieren.
    6. Wählen Sie Warteschlange speichern &aus.
    7. Führen Sie nach erfolgreicher Ausführung dieser Pipeline einen POST API-Aufruf mit gültigem JSON-Code im Text für aus https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Sie sollten jetzt eine Codeantwort mit 200 status erhalten.