Delen via

Bronnen in YAML-pijplijnen

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

In dit artikel worden middelen voor YAML-pipelines besproken. Een resource is alles wat door een pijplijn wordt gebruikt en onafhankelijk van de pijplijn bestaat. Nadat u een resource hebt gedefinieerd, kunt u deze overal in uw pijplijn gebruiken.

Resources bieden volledige traceerbaarheid voor de services die uw pijplijn gebruikt, zoals de versie, artefacten, gekoppelde commits en werkitems. U kunt uw DevOps-werkstromen volledig automatiseren door u te abonneren op het activeren van gebeurtenissen in uw resources.

Hulpbronnenschema

Resources in YAML vertegenwoordigen bronnen van pijplijnen, builds, opslagplaatsen, containers, pakketten en webhooks. Zie de resourcedefinitie in de YAML-schemareferentie voor Azure Pipelines voor volledige schemagegevens.

Wanneer een resource een pijplijn activeert, worden de volgende variabelen ingesteld:

resources.triggeringAlias
resources.triggeringCategory

De variabele Build.Reason moet ResourceTrigger zijn om deze waarden in te stellen. De waarden zijn leeg als een resource de pijplijnuitvoering niet heeft geactiveerd.

Definitie van pijplijnresources

Als u een pijplijn hebt die artefacten produceert, kunt u de artefacten gebruiken door een pipelines resource te definiëren. Alleen Azure Pipelines kunnen de pipelines resource gebruiken. U kunt triggers instellen voor uw continue implementatiewerkstromen op pijplijnresources.

In uw resourcedefinitie is pipeline een unieke waarde die u later in uw pijplijn kunt gebruiken om naar de bijbehorende resource te verwijzen. Dit source is de naam van de pijplijn die het pijplijnartefact heeft geproduceerd. Zie de definitie resources.pipelines.pipeline voor volledige schema-informatie.

U gebruikt het label dat door pipeline is gedefinieerd om naar de pijplijnresource te verwijzen vanuit andere delen van uw pijplijn, zoals bij het gebruik van pijplijnresourcevariabelen of bij het downloaden van artefacten. Zie Artefacten downloaden voor een alternatieve manier om pijplijnartefacten te downloaden.

Belangrijk

Wanneer u een pijplijnresource-trigger definieert:

  • Als de pipeline resource afkomstig is van dezelfde opslagplaats als de huidige pijplijn, of als het activeren self dezelfde vertakking en commit volgt waarop de gebeurtenis wordt gegenereerd.
  • Als de resource van de pijplijn afkomstig is uit een andere opslagplaats, zullen de huidige triggers van de pijplijn worden geactiveerd op de standaardbranch van de bronopslagplaats pipeline.

Voorbeeld van pijplijnresourcedefinities

In het volgende voorbeeld worden artefacten uit een pijplijn binnen hetzelfde project gebruikt.

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

Als u een pijplijn uit een ander project wilt gebruiken, neemt u de projectnaam en de bronnaam op. In het volgende voorbeeld wordt branch gebruikt om de standaardversie te bepalen wanneer de pijplijn handmatig of volgens schema wordt geactiveerd. De invoer voor de vertakking mag geen jokertekens bevatten.

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

In het volgende voorbeeld ziet u een pijplijnresource met een eenvoudige trigger.

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

In het volgende voorbeeld ziet u een pijplijnresource trigger met vertakkingsvoorwaarden.

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

In het volgende voorbeeld worden filters gebruikt stages voor het evalueren van triggervoorwaarden voor CD-pijplijnen. Fasen gebruiken de AND operator. Wanneer alle opgegeven fasen zijn voltooid, wordt de CD-pijplijn geactiveerd.

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

In het volgende voorbeeld worden filters gebruikt tags voor de standaardversie-evaluatie en voor triggers. Tags gebruiken de AND operator.

De tags instellingen zijn ingesteld voor de continue integratie (CI-) of CD-pijplijn. Deze tags verschillen van de tags die zijn ingesteld op vertakkingen in de Git-opslagplaats.

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

Versie-evaluatie van pijplijnartefacten

De versie van de artefacten in de resourcepijplijn hangt af van hoe de pijplijn wordt geactiveerd.

Handmatige of geplande actie

Als de pijplijnuitvoering handmatig wordt geactiveerd of gepland, definiëren de waarden van de version, branchen tags eigenschappen de artefactversie. De branch invoer kan geen jokertekens hebben. De tags eigenschappen gebruiken de AND operator.

Opgegeven eigenschappen Artefact-versie
version De artefacten uit de build met het opgegeven uitvoeringsnummer
branch De producten van de meest recente build die is uitgevoerd op de opgegeven branch
tags lijst De artefacten uit de nieuwste build met alle opgegeven tags
branch en tags lijst De artefacten van de nieuwste build die is uitgevoerd op de opgegeven tak met alle opgegeven tags.
version en branch De artefacten van de build met het opgegeven runnummer en de opgegeven vertakking.
Geen De artefacten van de nieuwste bouw in alle takken

De volgende pipeline resourcedefinitie gebruikt de branch en tags eigenschappen om de standaardversie te evalueren wanneer de pijplijn handmatig of gepland wordt geactiveerd. Wanneer u de pijplijn handmatig activeert om uit te voeren, is de versie van de MyCIAlias pijplijnartefacten de meest recente build die is gedaan op de main vertakking met de Production en PrepProduction tags.

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

Trigger voor voltooiing van hulpbronnenpijplijn

Wanneer een pijplijn wordt geactiveerd omdat een van zijn bronpijplijnen is voltooid, is de artefact-versie de versie van de trigger-pijplijn. De waarden van de version, branchen tags eigenschappen worden genegeerd.

Opgegeven triggers Resultaat
branches Een nieuwe pipeline-run start wanneer de resourcepijplijn een uitvoering op een van de include vertakkingen succesvol voltooit.
tags Een nieuwe pijplijnuitvoering wordt geactiveerd wanneer de resourcepijplijn met succes een run voltooit die is getagd met alle opgegeven tags.
stages Er wordt een nieuwe pijplijnuitvoering geactiveerd wanneer de resourcepijplijn de opgegeven stages met succes heeft uitgevoerd.
branches, tags en stages Een nieuwe pijplijnuitvoering wordt geactiveerd wanneer de resource-uitvoering voldoet aan alle voorwaarden voor branches, tags en fasen.
trigger: true Een nieuwe pijplijnuitvoering wordt geactiveerd wanneer de bronpijplijn een uitvoering met succes voltooit.
Niets Er worden geen nieuwe pijplijndraaien getriggerd wanneer de resourcepijplijn met succes een uitvoering voltooit.

De volgende pijplijn wordt uitgevoerd wanneer de SmartHotel-CI resource-pijplijn uitgevoerd wordt.

  • Wordt uitgevoerd op een van de releases vertakkingen of op de main vertakking
  • Is getagd met zowel Verified als Signed
  • Voltooit zowel de Production als de PreProduction fasen
resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

Artefact van de pijplijn downloaden

De download stap downloadt artefacten die zijn gekoppeld aan de huidige uitvoering of aan een andere pijplijnbron.

Alle artefacten uit de huidige pijplijn en alle pipeline bijbehorende resources worden automatisch gedownload en beschikbaar gemaakt aan het begin van elke implementatietaak. U kunt dit gedrag buiten werking stellen door download in te stellen op none, of door een andere pijplijnresource-id op te geven.

Normale taakartefacten worden niet automatisch gedownload. Gebruik download expliciet wanneer dat nodig is.

Artefacten van de pipeline resource worden gedownload naar de $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> folder. Zie Pijplijnartefacten publiceren en downloaden voor meer informatie.

Met de optionele artifact eigenschap worden artefactnamen opgegeven. Als dit niet is opgegeven, worden alle beschikbare artefacten gedownload. De optionele patterns eigenschap definieert patronen die bestanden vertegenwoordigen die moeten worden opgenomen. Zie de definitie steps.download voor volledige schema-informatie.

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

Pijplijnresourcevariabelen

In elke uitvoering zijn de metagegevens voor een pijplijnresource beschikbaar voor alle taken als vooraf gedefinieerde variabelen. Deze variabelen zijn alleen tijdens runtime beschikbaar voor uw pijplijn en kunnen daarom niet worden gebruikt in sjabloonexpressies, die tijdens het compileren van pijplijnen worden geëvalueerd.

Zie Metagegevens van pijplijnresources als vooraf gedefinieerde variabelen voor meer informatie. Zie Variabelen definiëren voor meer informatie over de syntaxis van variabelen.

In het volgende voorbeeld worden de vooraf gedefinieerde variabele waarden voor de myresourcevars pijplijnresource geretourneerd.

resources:
  pipelines:
  - pipeline: myresourcevars
    source: mypipeline
    trigger: true 

steps:
- script: |
    echo $(resources.pipeline.myresourcevars.pipelineID)
    echo $(resources.pipeline.myresourcevars.runName)
    echo $(resources.pipeline.myresourcevars.runID)
    echo $(resources.pipeline.myresourcevars.runURI)
    echo $(resources.pipeline.myresourcevars.sourceBranch)
    echo $(resources.pipeline.myresourcevars.sourceCommit)
    echo $(resources.pipeline.myresourcevars.sourceProvider)
    echo $(resources.pipeline.myresourcevars.requestedFor)
    echo $(resources.pipeline.myresourcevars.requestedForID)

Bouw een resourcedefinitie

Als u een extern CI-buildsysteem hebt dat artefacten produceert, kunt u met builds resources artefacten beheren. Een build resource kan afkomstig zijn van elk extern CI-systeem, zoals Jenkins, TeamCity of CircleCI.

De builds categorie kan worden uitgebreid. U kunt een extensie schrijven om artefacten van uw buildservice te gebruiken en een nieuw type service te introduceren als onderdeel van builds.

In de build definitie is version standaard de meest recente geslaagde build. De trigger functie is niet standaard ingeschakeld en moet expliciet worden ingesteld. Zie de definitie resources.builds.build voor volledige schemagegevens.

In het volgende voorbeeld is Jenkins de resource type.

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

Belangrijk

Triggers worden alleen ondersteund voor gehoste Jenkins, waarbij Azure DevOps een lijn van zicht heeft met de Jenkins-server.

De downloadBuild-taak

De resource-artefacten worden niet automatisch gedownload in uw build. Als u artefacten van de build resource als onderdeel van uw taken wilt gebruiken, moet u de downloadBuild taak expliciet toevoegen. U kunt het downloadgedrag voor elke implementatie of taak aanpassen.

Deze taak wordt automatisch omgezet in de bijbehorende downloadtaak voor het type build resource dat door de runtime wordt gedefinieerd. Artefacten van de build resource worden gedownload naar de $(PIPELINE.WORKSPACE)/<build-identifier>/ map.

In de downloadBuild definitie geeft u de resource op waaruit artefacten moeten worden gedownload. De optionele artifact eigenschap geeft artefacten op die moeten worden gedownload. Als dit niet is opgegeven, worden alle artefacten die zijn gekoppeld aan de resource gedownload.

De optionele patterns eigenschap definieert een minimatch-pad of lijst met minimatch-paden die moeten worden gedownload. Als dit leeg is, wordt het hele artefact gedownload. Met het volgende fragment worden bijvoorbeeld alleen de *.zip bestanden gedownload.

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

Zie de steps.downloadBuild-definitie voor volledige schema-informatie.

Definitie van opslagbronnen

Met repository het trefwoord kunt u een externe opslagplaats opgeven. U kunt deze resource gebruiken als uw pijplijn sjablonen in een andere opslagplaats heeft of als u multi-repo uitchecken wilt gebruiken met een opslagplaats waarvoor een serviceverbinding is vereist. U moet het systeem op de hoogte stellen van deze opslagplaatsen.

Voorbeeld:

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

Zie de definitie resources.repositorys.repository voor volledige schema-informatie.

Resourcetypen voor repositories

Azure Pipelines ondersteunt de volgende waarden voor het type opslagplaats: git, github, githubenterpriseen bitbucket.

Type Naamwaarde Voorbeeld
type: git Een andere opslagplaats in hetzelfde project of dezelfde organisatie. Hetzelfde project: name: otherRepo
Een ander project in dezelfde organisatie: name: otherProject/otherRepo.
type: github Volledige naam van de GitHub-opslagplaats, inclusief de gebruiker of organisatie. name: Microsoft/vscode
type: githubenterprise Volledige naam van de GitHub Enterprise-opslagplaats, inclusief de gebruiker of organisatie. name: Microsoft/vscode
type: bitbucket Volledige naam van de Bitbucket Cloud-opslagplaats, inclusief de gebruiker of organisatie. name: MyBitbucket/vscode

Resourcevariabelen voor opslagplaatsen

In elke uitvoering zijn de volgende metagegevens voor een opslagplaatsresource beschikbaar voor alle taken in de vorm van runtimevariabelen. Dit <Alias> is de id die u uw opslagplaatsresource geeft.

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

In het volgende voorbeeld is een opslagplaatsresource met een alias van common, dus de resourcevariabelen van de opslagplaats worden geopend met behulp van resources.repositories.common.*.

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

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

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

In elke uitvoering zijn de volgende metagegevens voor een opslagplaatsresource beschikbaar voor alle taken in de vorm van runtimevariabelen. Dit <Alias> is de identificatie die u aan uw opslagplaatsbron geeft.

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

In het volgende voorbeeld is een opslagplaatsresource met een alias van common, dus de resourcevariabelen van de opslagplaats worden geopend met behulp van resources.repositories.common.*.

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

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

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

Trefwoord controleren voor repositories

Repositories van de repository resource worden niet automatisch in uw taken gesynchroniseerd. Gebruik het checkout trefwoord om een opslagplaats op te halen die is gedefinieerd als onderdeel van de repository resource. Zie de definitie steps.checkout voor volledige schemagegevens.

Zie Meerdere opslagplaatsen in uw pijplijn bekijken voor meer informatie.

Definitie van containerresources

Als u container-images in uw CI/CD-pijplijnen wilt gebruiken, kunt u containers resources gebruiken. Een container resource kan een openbaar of persoonlijk Docker-register of een Azure Container Registry-exemplaar zijn.

U kunt een generieke containerresource-afbeelding gebruiken als onderdeel van uw taak of deze resource gebruiken voor containertaken. Als uw pijplijn ondersteuning van een of meer services vereist, moet u servicecontainers maken en er verbinding mee maken. U kunt volumes gebruiken om gegevens tussen services te delen.

Als u afbeeldingen uit een Docker-register als onderdeel van uw pijplijn wilt gebruiken, kunt u een generieke containerhulpbron definiëren. Er is geen type trefwoord vereist. Voorbeeld:

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

Zie de definitie resources.containers.container voor volledige schema-informatie.

Notitie

De enabled: 'true' syntaxis voor het inschakelen van containertriggers voor alle afbeeldingstags verschilt van de syntaxis voor andere resourcetriggers. Zorg ervoor dat u de juiste syntaxis gebruikt voor specifieke resources.

Azure Container Registry-brontype

Als u uw afbeeldingen van Azure Container Registry wilt gebruiken, kunt u het containertype van eerste klasse acr gebruiken. U kunt dit resourcetype gebruiken als onderdeel van uw taken en automatische pijplijntriggers inschakelen.

U hebt inzender- of eigenaarsmachtigingen voor Azure Container Registry nodig om automatische pijplijntriggers te kunnen gebruiken. Zie Azure Container Registry-rollen en -machtigingen voor meer informatie.

Als u het acr resourcetype wilt gebruiken, moet u de azureSubscription, resourceGroupen repository waarden voor uw Azure-containerregister opgeven. Voorbeeld:

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

Notitie

Triggerevaluatie vindt alleen plaats op de standaardbranch. Zorg ervoor dat u de juiste standaardbranch instelt of het YAML-bestand samenvoegt in de huidige standaardbranch. Bezoek De standaardbranch van de pijplijn voor meer informatie over hoe je de standaardbranch van de pijplijn kunt wijzigen.

Containerresourcevariabelen

Zodra u een container als een resource definieert, worden metagegevens van containerafbeeldingen als variabelen doorgegeven aan de pijplijn. Informatie zoals installatiekopieën, registry en verbindingsgegevens zijn toegankelijk voor alle taken die worden gebruikt in uw container-implementatietaken.

Containerresourcevariabelen werken met Docker en Azure Container Registry. U kunt geen containerresourcevariabelen gebruiken voor lokale containerafbeeldingen. De location variabele is alleen van toepassing op het acr type containerbronnen.

In het volgende voorbeeld ziet u een Azure Resource Manager-serviceverbinding met de naam arm-connection. Zie Azure-containerregisters, opslagplaatsen en installatiekopieën voor meer informatie.

resources:
  containers:
  - container: mycontainer
    type: ACR
    azureSubscription: arm-connection
    resourceGroup: rg-storage-eastus
    registry: mycontainerregistry
    repository: hello-world
    trigger:
      tags:
      - latest

steps:
- script: echo |
    echo $(resources.container.mycontainer.type)
    echo $(resources.container.mycontainer.registry)
    echo $(resources.container.mycontainer.repository)
    echo $(resources.container.mycontainer.tag)
    echo $(resources.container.mycontainer.digest)
    echo $(resources.container.mycontainer.URI)
    echo $(resources.container.mycontainer.location)

Pakkettenresourcedefinitie

U kunt NuGet- en NPM GitHub-pakketten gebruiken als resources in YAML-pijplijnen. Als u automatische pijplijntriggers wilt inschakelen wanneer een nieuwe pakketversie wordt uitgebracht, stelt u de trigger eigenschap in op true.

Wanneer u package resources definieert, specificeert u het pakket <Repository>/<Naam> in de name-eigenschap en configureert u het pakket type als NuGet of npm. Als u GitHub-pakketten wilt gebruiken, gebruikt u verificatie op basis van een persoonlijk toegangstoken (PAT) en maakt u een GitHub-serviceverbinding die gebruikmaakt van de PAT.

Zie de definitie resources.packages.package voor volledige schema-informatie.

Pakketten worden standaard niet automatisch in taken gedownload. Gebruik getPackage om te downloaden.

Het volgende voorbeeld heeft een GitHub-serviceverbinding genaamd pat-contoso en een GitHub npm-pakket genaamd contoso. Zie GitHub-pakketten voor meer informatie.

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

pool:
  vmImage: 'ubuntu-latest'

steps:
- getPackage: contoso

Definitie van webhooks-resource

Notitie

Webhooks zijn uitgebracht in Azure DevOps Server 2020.1.

U kunt artefacten gebruiken en geautomatiseerde triggers inschakelen met pijplijn-, container-, bouw- en pakketbronnen. U kunt deze resources echter niet gebruiken om uw implementaties te automatiseren op basis van externe gebeurtenissen of services.

Met de webhooks resource in YAML-pijplijnen kunt u uw pijplijnen integreren met externe services zoals GitHub, GitHub Enterprise, Nexus en Artifactory om werkstromen te automatiseren. U kunt zich abonneren op externe gebeurtenissen via webhooks en de gebeurtenissen gebruiken om uw pijplijnen te activeren.

Webhooks automatiseren uw werkstroom op basis van een externe webhookgebeurtenis die niet wordt ondersteund door eersteklas resources, zoals pijplijnen, builds, containers of pakketten. Voor on-premises services waarvoor Azure DevOps geen inzicht heeft in het proces, kunt u webhooks configureren voor de service en uw pijplijnen automatisch activeren.

Als u zich wilt abonneren op een webhook-gebeurtenis, definieert u een webhookresource in uw pijplijn en wijst u deze aan op een binnenkomende webhookserviceverbinding. U kunt ook meer filters definiëren voor de webhookresource, op basis van de JSON-nettoladinggegevens, om de triggers voor elke pijplijn aan te passen.

Wanneer de webhookservice een webhookgebeurtenis ontvangt, wordt er een nieuwe uitvoering gestart voor alle pijplijnen die zich hebben geabonneerd op de webhookgebeurtenis. U kunt de JSON-payloadgegevens in uw taken gebruiken als variabelen door het formaat ${{ parameters.<WebhookAlias>.<JSONPath>}} te gebruiken.

Zie de definitie resources.webhooks.webhook voor volledige schema-informatie.

In het volgende voorbeeld wordt een webhookresource gedefinieerd:

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

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

Webhook triggers

Als u webhooktriggers wilt configureren, stelt u eerst een webhook in uw externe service in, met de volgende informatie:

  • Aanvraag-URL: https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
  • Geheim (optioneel): Als u uw JSON-nettolading wilt beveiligen, geeft u een geheime waarde op.

Vervolgens maakt u een nieuwe binnenkomende webhookserviceverbinding. Voor dit serviceverbindingstype definieert u de volgende informatie:

  • WebHooknaam: hetzelfde als de webhook die is gemaakt in uw externe service.
  • Geheim (optioneel): wordt gebruikt om de HMAC-SHA1-hash van de nettolading te verifiëren voor verificatie van de binnenkomende aanvraag. Als u een geheim hebt gebruikt bij het maken van uw webhook, moet u hetzelfde geheim opgeven.
  • HTTP-header: de HTTP-header in de aanvraag die de HMAC-SHA1-hashwaarde van de payload bevat voor verificatie van de aanvraag. Bijvoorbeeld, de GitHub-aanvraagheader is X-Hub-Signature.

Schermopname van de binnenkomende webhookserviceverbinding.

Als u uw pijplijn wilt activeren met behulp van een webhook, moet u een POST aanvraag indienen bij https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview. Dit eindpunt is openbaar beschikbaar en heeft geen autorisatie nodig. De aanvraag moet een hoofdtekst hebben zoals in het volgende voorbeeld:

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

Notitie

Toegang tot gegevens uit de aanvraagbody van de webhook kan leiden tot onjuiste YAML. De pijplijnstap - script: echo ${{ parameters.WebHook.resource.message }} haalt bijvoorbeeld het hele JSON-bericht op, waarmee ongeldige YAML wordt gegenereerd. Elke pijplijn die via deze webhook wordt geactiveerd, wordt niet uitgevoerd, omdat de gegenereerde YAML ongeldig is geworden.

In het volgende codefragment ziet u een ander voorbeeld waarin webhookfilters worden gebruikt.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          
      connection: MyWebhookConnection    
      filters:
        - path: repositoryName      
          value: maven-releases     
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

Handmatige versiekiezer voor resources

Wanneer u handmatig een CD YAML-pijplijn activeert, evalueert Azure Pipelines automatisch de standaardversies voor de resources die in de pijplijn zijn gedefinieerd, op basis van de opgegeven invoer. Azure Pipelines beschouwt echter alleen voltooide CI-uitvoeringen bij het evalueren van de standaardversie voor geplande triggers of als u niet handmatig een versie kiest.

U kunt de resourceversiekiezer gebruiken om handmatig een andere versie te kiezen wanneer u een uitvoering maakt. De resource-versiekiezer wordt ondersteund voor pijplijnresources, buildresources, opslagplaatsresources, containerresources en pakketresources.

Voor pijplijnbronnen kunt u alle beschikbare uitvoeringen over alle takken bekijken, deze zoeken op basis van het pijplijnnummer of de tak, en een uitvoering kiezen die geslaagd, mislukt of in uitvoering is. Deze flexibiliteit zorgt ervoor dat u uw CD-pijplijn kunt uitvoeren als u zeker weet dat een uitvoering alle benodigde artefacten heeft geproduceerd. Je hoeft niet te wachten totdat een CI-uitvoering is voltooid, en je hoeft het ook niet opnieuw uit te voeren vanwege een niet-gerelateerde stapfout.

Als u de functie voor het kiezen van resourceversies wilt gebruiken, selecteert u in het deelvenster Pijplijn uitvoeren eerst Resources, daarna selecteert u een resource en kiest u een specifieke versie uit de lijst met beschikbare versies.

Schermopname van de versiekiezer voor resourcebestanden in de repository.

Voor resources waar u geen beschikbare versies kunt ophalen, zoals GitHub-pakketten, biedt de versiekiezer een tekstveld, zodat u de versie voor de uitvoering kunt invoeren die u kunt kiezen.

Resource-autorisatie in YAML-pijplijnen

Resources moeten worden geautoriseerd voordat ze kunnen worden gebruikt in pijplijnen. Resource-eigenaren beheren de gebruikers en pijplijnen die toegang hebben tot hun resources. Er zijn verschillende manieren om een YAML-pijplijn te autoriseren voor het gebruik van resources.

  • Gebruik de ervaring met resourcebeheer om alle pijplijnen te autoriseren om toegang te krijgen tot de resource. Variabele groepen en beveiligde bestanden worden bijvoorbeeld beheerd op de pagina Bibliotheek onder Pijplijnen en agentgroepen en serviceverbindingen worden beheerd in projectinstellingen. Deze autorisatie is handig als u de toegang tot resources niet hoeft te beperken, zoals voor testbronnen.

  • Wanneer u een pijplijn maakt, worden alle resources waarnaar wordt verwezen in het YAML-bestand automatisch geautoriseerd voor gebruik door de pijplijn als u de gebruikersrol voor deze resources hebt.

  • Als u een resource toevoegt aan een YAML-bestand en de build mislukt met een dergelijke fout Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use., ziet u een optie om de resources op de mislukte build te autoriseren.

    Als u lid bent van de gebruikersrol voor de resource, kunt u deze optie selecteren en de resource autoriseren voor de mislukte build. Zodra de resource is geautoriseerd, kunt u een nieuwe build starten.

  • Controleer of de beveiligingsrollen voor de agentgroep voor uw project juist zijn.

Goedkeuringscontroles voor middelen

U kunt goedkeuringscontroles en sjablonen gebruiken om handmatig te beheren wanneer een resource wordt uitgevoerd. nl-NL: Met de vereiste goedkeuringseis voor sjablonen kunt u vereisen dat elke pijplijn met behulp van een resource of omgeving is afgeleid van een specifieke YAML-sjabloon.

Als u een vereiste sjabloongoedkeuring instelt, zorgt u ervoor dat uw resource alleen onder specifieke voorwaarden wordt gebruikt en verbetert de beveiliging. Zie Sjablonen gebruiken voor beveiliging voor meer informatie over het verbeteren van de beveiliging van pijplijnen met sjablonen.

Traceerbaarheid

Azure Pipelines biedt volledige tracering voor alle resources die worden gebruikt op pijplijn- of implementatietaakniveau.

Traceerbaarheid van pijplijnen

Azure Pipelines toont de volgende informatie voor elke pijplijnuitvoering:

  • Als een resource de pijplijn heeft geactiveerd, dan is dat de bron die het proces in gang heeft gezet.
  • De hulpbronversie en de verbruikte artefacten.
  • Commits verbonden met de resource.
  • Werkitems die aan elke resource zijn gekoppeld.

Traceerbaarheid van de omgeving

Wanneer een pijplijn in een omgeving wordt geïmplementeerd, ziet u een lijst met resources die worden verbruikt. De weergave bevat middelen die worden gebruikt als onderdeel van de uitrolopdrachten en de bijbehorende commits en werkitems.

Schermafbeelding die commits in een omgeving toont.

Informatie over gekoppelde CD-pijplijnen in CI-pijplijnen

Als u end-to-end traceerbaarheid wilt bieden, kunt u bijhouden welke CD-pijplijnen een specifieke CI-pijplijn via de pipelines resource gebruiken. Als andere pijplijnen uw CI-pijplijn gebruiken, ziet u een tabblad Gekoppelde pijplijnen in de weergave Uitvoeren . De weergave toont alle CD YAML-pijplijnuitvoeringen die gebruikmaken van uw CI-pijplijn en de bijbehorende artefacten.

Schermopname van informatie over CD-pijplijnen in een CI-pijplijn.

Problemen met resourcetriggers

Resource triggers kunnen niet worden uitgevoerd omdat:

  • De bron van de opgegeven serviceverbinding is ongeldig, er zijn syntaxisfouten in de trigger of de trigger is niet geconfigureerd.
  • Triggervoorwaarden komen niet overeen.

Als u wilt zien waarom pijplijntriggers niet kunnen worden uitgevoerd, selecteert u het menu-item Triggerproblemen op de pagina pijplijndefinitie. Triggerproblemen is alleen beschikbaar voor niet-repositorybronnen.

Schermopname van triggerproblemen op de hoofdpijplijnpagina.

Op de pagina Problemen met triggers beschrijven de foutberichten en waarschuwingsberichten waarom de trigger is mislukt.

Schermopname die de ondersteunbaarheid van triggerkwesties toont.

Veelgestelde vragen

Wanneer moet ik pijplijnbronnen, de downloadsnelkoppeling of de taak Pijplijnartefacten downloaden gebruiken?

Het gebruik van een pipelines resource is een manier om artefacten uit een CI-pijplijn te gebruiken en ook geautomatiseerde triggers te configureren. Een resource biedt u volledig zicht op het proces door de verbruikte versie, artefacten, commits en werkitems weer te geven. Wanneer u een pijplijnresource definieert, worden de bijbehorende artefacten automatisch gedownload in implementatietaken.

U kunt de download-snelkoppeling gebruiken om de artefacten te downloaden in buildtaken of om het gedrag van downloaden in implementatietaken te overschrijven. Zie de definitie steps.download voor meer informatie.

De taak 'Download Pipeline Artifacts' biedt geen overzicht of triggers, maar soms is het nuttig om deze taak direct te gebruiken. U hebt bijvoorbeeld een scripttaak opgeslagen in een andere sjabloon waarvoor artefacten uit een build moeten worden gedownload. Of misschien wilt u geen pijplijnresource toevoegen aan een sjabloon. Als u afhankelijkheden wilt voorkomen, kunt u de taak Pijplijnartefacten downloaden gebruiken om alle buildgegevens door te geven aan een taak.

Hoe kan ik een pijplijn starten wanneer mijn Docker Hub-afbeelding wordt bijgewerkt?

De trigger voor containerresources is niet beschikbaar voor Docker Hub voor YAML-pijplijnen, dus u moet een klassieke release-pijplijn instellen.

  1. Maak een nieuwe Docker Hub-serviceverbinding.
  2. Maak een klassieke release-pijplijn en voeg een Docker Hub-artefact toe. Stel uw serviceverbinding in en selecteer de naamruimte, opslagplaats, versie en bronalias.
  3. Selecteer de trigger en zet de trigger voor continue implementatie aan door te kiezen voor Inschakelen. Elke Docker-push die plaatsvindt in de geselecteerde opslagplaats, maakt een release.
  4. Maak een nieuwe fase en taak. Voeg twee taken, Docker-aanmelding en Bash toe.
    • De Docker-taak heeft de login actie en meldt u aan bij Docker Hub.
    • De Bash-taak wordt uitgevoerd docker pull <hub-user>/<repo-name>[:<tag>].

Hoe kan ik mijn webhook valideren en problemen oplossen?

  1. Maak een serviceverbinding.

  2. Verwijs naar uw serviceverbinding en geef uw webhook een naam in de webhooks sectie.

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. Voer uw pijplijn uit. De webhook wordt in Azure gemaakt als een gedistribueerde taak voor uw organisatie.

  4. Voer een API-aanroep POST uit met geldige JSON in de hoofdtekst naar https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Als u een antwoord met statuscode 200 ontvangt, is uw webhook gereed voor gebruik in uw pijplijn.

Als u een antwoord met een 500-statuscode en de fout Cannot find webhook for the given webHookId ... ontvangt, bevindt uw code zich mogelijk in een vertakking die niet uw standaardbranch is. Ga als volgt te werk om dit probleem op te lossen:

  1. Selecteer Bewerken op de pijplijnpagina.
  2. Selecteer Triggers in het menu Meer acties.
  3. Selecteer het tabblad YAML en selecteer bronnen ophalen vervolgens.
  4. Werk uw functiebranch bij onder Standaardbranch voor handmatige en geplande builds.
  5. Selecteer Opslaan en wachtrij.
  6. Nadat deze pijplijn succesvol is uitgevoerd, voert u een API-aanroep POST uit met geldige JSON in de body naar https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. U zou nu een respons met een statuscode 200 moeten ontvangen.

Gerelateerde inhoud