Definieren von Ressourcen in YAML

  • Artikel
  • 24 Minuten Lesedauer

Azure DevOps Services

Ressourcen in YAML stellen Quellen von Pipelines, Builds, Repositorys, Containern, Paketen und Webhooks dar. Ressourcen bieten Ihnen auch die vollständige Rückverfolgbarkeit der Dienste, die in Ihrer Pipeline verwendet werden, einschließlich der Version, Artefakte, zugeordneten Commits und Arbeitsaufgaben. Wenn Sie eine Ressource definieren, kann sie an einer beliebigen Stelle in Ihrer Pipeline genutzt werden. Außerdem können Sie Ihren DevOps Workflow vollständig automatisieren, indem Sie Ereignisse auf Ihren Ressourcen auslösen.

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 für diese Werte gelten, um festgelegt zu werden ResourceTrigger .

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. pipelinesist 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 ein eindeutiger Wert, pipeline mit dem Sie später auf die Pipelineressource verweisen können. source ist der Name der Pipeline, die ein Artefakte erzeugt. Verwenden Sie die Bezeichnung, die durch pipeline den Verweis auf die Pipelineressource aus anderen Teilen der Pipeline definiert wird, z. B. beim Verwenden von Pipelineressourcenvariablen oder herunterladen von Artefakten.

Eine alternative Möglichkeit zum Herunterladen von Pipelines finden Sie in den Vorgängen in Pipeline Artifacts.

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 Ressourcenauslöser definieren, wenn seine Pipelineressource aus demselben Repository stammt (z. B. selbst) wie die aktuelle Pipeline, löst das Auslösen der gleichen Verzweigung und des Commits aus, auf dem das Ereignis ausgelöst wird. Wenn die Pipelineressource jedoch aus einem anderen Repository stammt, löst die aktuelle Pipeline in der Standardverzweigung des Self-Repositorys aus.

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 oder aufgrund einer geplanten Ausführung ausgelöst haben, wird die Version der Artefakte durch die Werte der Werte der version, branchund tags Eigenschaften definiert.

Angegebene Eigenschaften Artefaktversion
version Die Artefakte aus dem Build mit der angegebenen Ausführungsnummer
branch Die Artefakte aus dem neuesten Build, der auf der angegebenen Verzweigung ausgeführt wurde
tags Liste Die Artefakte aus dem neuesten Build mit allen angegebenen Tags
branch und tags Liste Die Artefakte aus dem neuesten Build, der auf der angegebenen Verzweigung ausgeführt wurde und über alle angegebenen Tags verfügt
Keiner Die Artefakte aus dem neuesten Build in allen Zweigen

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 Ihre Pipeline manuell auslösen, ist die Version der Artefakte der MyCIAlias Pipeline der neueste Build, der auf der main Verzweigung ausgeführt wurde und die die Production Und-Tags PrepProduction enthält.

Wenn Ihre Pipeline ausgelöst wird, da eine ihrer Ressourcenpipelinen abgeschlossen ist, ist die Version der Artefakte eine der auslösenden Pipelines. Die Werte der version, branchund tags Eigenschaften 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 Verzweigungen abgeschlossen hat.
tags Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ressourcenpipeline erfolgreich eine Ausführung abgeschlossen hat, die mit allen angegebenen Tags markiert ist.
stages Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ressourcenpipeline erfolgreich die angegebene Ausführung ausgeführt hat. stages
branches, tags und stages Eine neue Ausführung der aktuellen Pipeline wird ausgelöst, wenn die Ressourcenpipeline alle Verzweigungen, Tags und Stufen 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 ausgeführt, wenn die SmartHotel Pipelines auf einer der releases Verzweigungen oder auf der main Verzweigung ausgeführt werden, mit beiden Verified und , und Signedsie wird sowohl mit als auch mit den ProductionPreProduction Phasen markiert.

download für Pipelines

Alle Artefakte aus der aktuellen Pipeline und aus allen pipeline Ressourcen werden automatisch heruntergeladen und am Anfang jedes deployment Auftrags zur Verfügung gestellt. Sie können dieses Verhalten außer Kraft setzen. Weitere Informationen finden Sie unter Pipeline Artifacts. Reguläre "Job"-Artefakte 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

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

Pipelineressourcenvariablen

In jeder Ausführung sind die Metadaten für eine Pipelineressource für alle Aufträge in Form vordefinierter Variablen verfügbar. Dies <Alias> ist der Bezeichner, den Sie für Ihre Pipelineressource angegeben haben. Pipelineressourcenvariablen sind zur Laufzeit nur 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

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 Builds-Dienst zu nutzen und einen neuen Diensttyp als Teil von builds. Jenkins ist eine Art von Ressource in builds.

Wichtig

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

downloadBuild Aufgabe für Builds

Sie können Artefakte aus der Ressource als Teil Ihrer Aufträge mithilfe der builddownloadBuild Aufgabe nutzen. Basierend auf dem typ der build definierten Ressource wird dieser Vorgang automatisch in den entsprechenden Downloadvorgang für den Dienst während der Laufzeit aufgelöst.

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

Wichtig

build Ressourcenartefakte werden in Ihren Aufträgen/Bereitstellungsaufträgen nicht automatisch heruntergeladen. Sie müssen die downloadBuild Aufgabe explizit hinzufügen, um die Artefakte zu verwenden.

- 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 die Multi-Repo-Auscheckung 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  # identifier (A-Z, a-z, 0-9, and underscore)
    type: enum  # see the following "Type" topic
    name: string  # repository name (format depends on `type`)
    ref: string  # ref name to use; defaults to 'refs/heads/main'
    endpoint: string  # name of the service connection to use (for types that aren't Azure Repos)
    trigger:  # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos)
      branches:
        include: [ string ] # branch names which trigger a build
        exclude: [ string ] # branch names which won't
      tags:
        include: [ string ] # tag names which trigger a build
        exclude: [ string ] # tag names which won't
      paths:
        include: [ string ] # file paths which must match to trigger a build
        exclude: [ string ] # file paths which won't trigger a build

type

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

Angegebener Typ Ergebnis Beispiel
type: git Der name Wert bezieht sich auf ein anderes Repository im selben Projekt. name: otherRepo Um auf ein Repository in einem anderen Projekt innerhalb derselben Organisation zu verweisen, präfixieren Sie den Namen mit dem Namen dieses Projekts. z. B. name: OtherProject/otherRepo.
type: github Der name Wert ist der vollständige Name des GitHub-Repositorys und umfasst den Benutzer oder die Organisation. name: Microsoft/vscode
type: githubenterprise der name Wert ist der vollständige Name des GitHub Enterprise-Repositorys und umfasst den Benutzer oder die Organisation. name: Microsoft/vscode
type: bitbucket Der name Wert ist der vollständige Name des Bitbucket Cloud-Repositorys und umfasst den Benutzer oder die Organisation. name: MyBitbucket/vscode

GitHub Enterprise Repos erfordert eine GitHub Enterprise Dienstverbindung für die Autorisierung.

Bitbucket Cloud repos erfordert eine Bitbucket Cloud Service-Verbindung für die Autorisierung.

Verwenden checkout des Repositorys

Verwenden Sie checkout das Schlüsselwort, um Ihre Als Teil der repository Ressource definierten Repos zu nutzen.

Schema

steps:
- checkout: string  # identifier for your repository resource
  clean: boolean  # if true, execute `execute git clean -ffdx && git reset --hard HEAD` before fetching
  fetchDepth: number  # the depth of commits to ask Git to fetch; defaults to no limit
  lfs: boolean  # whether to download Git-LFS files; defaults to false
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules; defaults to not checking out submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1); defaults to a directory called `s`
  persistCredentials: boolean  # if 'true', leave the OAuth token in the Git config after the initial fetch; defaults to false

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

Weitere Informationen finden Sie unter "Auschecken mehrerer Repositorys in Ihrer Pipeline".

Definieren einer containers Ressource

Wenn Sie ein Containerimage als Teil Ihrer kontinuierlichen Integrations-/Kontinuierlichen Übermittlungspipeline (CI/CD) nutzen müssen, können Sie es mithilfe containersvon . Eine Containerressource kann eine öffentliche oder private Docker-Registrierung oder Azure Container Registry sein.

Wenn Sie Bilder aus der Docker-Registrierung als Teil Ihrer Pipeline verwenden müssen, können Sie eine generische Containerressource (nicht type schlüsselwort erforderlich) definieren.

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, möchten Sie Servicecontainer erstellen und verbinden. Sie können Volumes verwenden, um Daten zwischen Diensten zu teilen.

Sie können einen erstklassigen Containerressourcentyp für Azure Container Registry (ACR) verwenden, um Ihre ACR-Bilder zu nutzen. Dieser Ressourcentyp kann als Teil Ihrer Aufträge und auch zum Aktivieren von automatischen Pipelinetriggern verwendet werden.

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 Bildtags (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

Sobald Sie einen Container als Ressource definieren, werden Containerimagemetadaten in Form von Variablen an die Pipeline übergeben. Informationen wie Image, Registrierung und Verbindungsdetails sind für alle Aufträge zugänglich, die in Ihrem Container bereitgestellt 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 der Containerressourcen.

Definieren einer packages Ressource

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

Wenn Sie Ressourcen angebenpackage, 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 pat-basierte Authentifizierung (Personal Access Token), 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

Mit anderen Ressourcen (z. B. Pipelines, Container, Build und Pakete) 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 der webhooks Ressource können Sie Ihre Pipeline mit jedem externen Dienst integrieren und den Workflow automatisieren. Sie können alle externen Ereignisse über ihre Webhooks (GitHub, GitHub Enterprise, Nexus, Artefakte usw.) abonnieren und Ihre Pipelines auslösen.

Führen Sie die folgenden Schritte aus, um die Webhook-Trigger 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
    • Geheimer Schlüssel – Optional. Wenn Sie Ihre JSON-Nutzlast sichern müssen, geben Sie den Geheimen Wert 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:

    • Webhook-Name: Der Name des Webhooks sollte mit dem Webhook übereinstimmen, der in Ihrem externen Dienst erstellt wurde.
    • HTTP-Header – Der Name des HTTP-Headers in der Anforderung, die den HMAC-SHA1-Hashwert der Nutzlast für die Anforderungsüberprüfung enthält. Beispielsweise lautet der Anforderungsheader für GitHub "X-Hub-Signature".
    • Geheimer Schlüssel – Der geheime Schlüssel wird verwendet, um den HMAC-SHA1-Hash der Nutzlast zu überprüfen, der zur Überprüfung der eingehenden Anforderung (optional) verwendet wird. Wenn Sie beim Erstellen Ihres Webhooks einen Geheimschlüssel verwendet haben, müssen Sie denselben geheimen Schlüssel angeben.

    Incoming Webhook Service connection

  3. Ein neuer Ressourcentyp, der in YAML-Pipelines aufgerufen webhooks wird, wird eingeführt. Wenn Sie ein Webhook-Ereignis abonnieren möchten, definieren Sie eine Webhook-Ressource in Ihrer Pipeline, und zeigen Sie sie auf die Verbindung des eingehenden Webhook-Diensts. Sie können auch weitere Filter für die Webhook-Ressource definieren, basierend auf den JSON-Nutzlastdaten, um die Trigger für jede Pipeline anzupassen. Nutzen Sie die Nutzlastdaten in Form von Variablen in Ihren Aufträgen.

  4. Wenn die Eingehende Webhook-Dienstverbindung ein Webhook-Ereignis empfängt, wird eine neue Ausführung für alle Pipelines ausgelöst, die das Webhook-Ereignis abonniert haben. Sie können die JSON-Nutzlastdaten in Ihren Aufträgen mithilfe des Formats nutzen. ${{ 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 Webhook-Ereignis, das nicht von Ressourcen der ersten Klasse 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 Dialog "Ausführen erstellen"

Wenn Sie eine CD-YAML-Pipeline manuell auslösen, bewerten wir automatisch die Standardversion für die ressourcen, die in der Pipeline definiert sind, basierend auf den bereitgestellten Eingaben. Sie können jedoch beim Erstellen einer Ausführung eine andere Version aus der Ressourcenversionsauswahl auswählen.

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

  2. Wählen Sie eine Ressource aus, und wählen Sie 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 können Sie alle verfügbaren Ausführungen in allen Verzweigungen anzeigen. Suchen Sie sie basierend auf der Pipelinenummer oder Verzweigung. Wählen Sie eine Ausführung aus, die erfolgreich, fehlgeschlagen oder in der Bearbeitung ist. Diese Flexibilität stellt sicher, dass Sie Ihre CD-Pipeline ausführen können, wenn Sie sicher sind, dass alle Artefakte erstellt wurden, die Sie benötigen. Sie müssen nicht warten, bis die CI-Ausführung abgeschlossen oder erneut ausgeführt werden kann, da es sich um einen nicht verbundenen Phasenfehler in der CI-Ausführung handelt. Wir berücksichtigen jedoch nur die erfolgreich abgeschlossene CI-Ausführung, wenn wir die Standardversion für geplante Trigger auswerten oder wenn Sie die manuelle Versionsauswahl nicht verwenden.

Für Ressourcen, in denen Sie keine verfügbaren Versionen abrufen können, wie GitHub Pakete, werden ein Textfeld als Teil der Versionsauswahl angezeigt, damit Sie die Version für die Auswahl bereitstellen 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 berechtigt sein, die Ressource zu verwenden. Sehen Sie sich die folgenden Möglichkeiten an, wie Sie eine YAML-Pipeline autorisieren können.

  • Wechseln Sie zur Verwaltungsumgebung der Ressource. Beispielsweise werden variable Gruppen und sichere Dateien auf der Bibliotheksseite unter Pipelines verwaltet. Agentpools und Dienstverbindungen werden in Project Einstellungen verwaltet. Hier können Sie alle Pipelines autorisieren, auf diese Ressource zuzugreifen. Diese Autorisierung ist praktisch, wenn Sie keinen Zugriff auf eine Ressource einschränken müssen , z. B. Testressourcen.

  • Wenn Sie eine Pipeline zum ersten Mal erstellen, erhalten 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, schlägt der Build mit einem Fehler wie 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 fehlgeschlagenen 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.

  • Stellen Sie sicher, dass die Sicherheitsrollen des Agentpools für Ihr Projekt korrekt 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 Genehmigungsprüfung der Vorlage können Sie eine beliebige Pipeline mithilfe einer Ressource oder Umgebung auch aus einer bestimmten YAML-Vorlage benötigen. Durch Festlegen einer erforderlichen Vorlagengenehmigung wird die Sicherheit verbessert. 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 können.

Nachverfolgbarkeit

Wir bieten vollständige Ablaufverfolgung für alle Ressourcen, die auf Pipeline- oder Bereitstellungsauftragsebene verbraucht werden.

Ablaufverfolgung der Pipeline

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

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

    Resource trigger in a pipeline

  • Version der Ressource und der Artefakte, die verbraucht werden.

    Consumed artifacts in pipeline run

  • Commits, die jeder Ressource zugeordnet sind.

    Commits in pipeline run

  • Arbeitselemente, die jeder Ressource zugeordnet sind.

Nachverfolgbarkeit von Umgebungen

Wenn eine Pipeline in einer Umgebung bereitgestellt wird, können Sie eine Liste der Ressourcen anzeigen, die verbraucht werden. Die folgende Ansicht enthält Ressourcen, die als Teil der Bereitstellungsaufträge und deren zugeordneten Commits und Arbeitselemente verwendet werden.

Commits in environment

Anzeigen zugeordneter CD-Pipelines in CI-Pipelines

Um die End-to-End-Ablaufverfolgung bereitzustellen, können Sie nachverfolgen, welche CD-Pipelines eine ci-Pipeline verwenden. Sie können die Liste der CD YAML-Pipelines sehen, in denen eine CI-Pipeline über die pipeline Ressource verbraucht wird. Wenn andere Pipelines Ihre CI-Pipeline nutzen, wird in der Ausführungsansicht eine Registerkarte "Zugeordnete Pipelines" angezeigt. Hier finden Sie alle Pipelineläufe, die Ihre Pipeline und Artefakte davon nutzen.

CD pipelines information in CI pipeline

YAML-Ressourcenauslöserprobleme unterstützung und Ablaufverfolgung

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

Select Trigger Issues from the navigation.

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

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

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

    Trigger issues supportability

Nächste Schritte

Hinzufügen und Verwenden von Variablengruppen

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 auch automatisierte Trigger zu konfigurieren. Eine Ressource bietet Ihnen vollständige Sichtbarkeit im Prozess, indem Sie die verbrauchte Version, Artefakte, Commits und Arbeitselemente anzeigen. Wenn Sie eine Pipelineressource definieren, werden die zugeordneten Artefakte automatisch in Bereitstellungsaufträgen heruntergeladen.

Sie können die Artefakte in Buildaufträgen herunterladen oder das Downloadverhalten in Bereitstellungsaufträgen downloadaußer Kraft setzen. Die download Aufgabe verwendet intern die Downloadpipeline Artifacts Aufgabe.

Warum sollte ich anstelle der Downloadpipeline Artifacts Aufgabe verwendenresources?

Wenn Sie die Downloadpipeline Artifacts Aufgabe direkt verwenden, verpassen Sie die Ablaufverfolgung und Trigger. Manchmal ist es sinnvoll, die Downloadpipeline Artifacts Aufgabe direkt zu verwenden. Beispielsweise haben Sie möglicherweise eine Skriptaufgabe, die in einer anderen Vorlage gespeichert ist, und die Skriptaufgabe erfordert Artefakte aus einem Build, das heruntergeladen werden soll. 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 Downloadpipeline Artifacts Aufgabe verwenden, um alle Buildinformationen an einen Vorgang zu übergeben.

Wie kann ich eine Pipeline ausführen, wenn mein Docker Hub Image aktualisiert wird?

Sie müssen eine klassische Releasepipeline einrichten, da der Containerressourcenauslöser 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 Artefakte 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 fortlaufenden Bereitstellungsauslöser auf "Aktivieren" aus. Sie erstellen jedes Mal eine Version, wenn ein Docker-Push im ausgewählten 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 protokolliert Sie in Docker Hub.

  • Die Bash-Aufgabe wird ausgeführt docker pull <hub-user>/<repo-name>[:<tag>]. Ersetzen hub-userSie , , repo-nameund tag mit Ihren Werten.

    Add Docker login and Bash tasks.