Resources in YAML-pijplijnen

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

In dit artikel worden resources voor YAML-pijplijnen besproken. Een resource is alles wat wordt gebruikt door een pijplijn die buiten 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 door uw pijplijn worden gebruikt, waaronder de versie, artefacten, gekoppelde doorvoeringen en werkitems. U kunt uw DevOps-werkstromen volledig automatiseren door u te abonneren op het activeren van gebeurtenissen in uw resources.

Resourcesschema

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 zijn ResourceTrigger voor deze waarden om deze waarden in te stellen. De waarden zijn leeg als een resource de pijplijnuitvoering niet heeft geactiveerd.

Resourcedefinitie pijplijnen

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 werkstromen voor continue implementatie (CD) op een pijplijnresource.

In uw resourcedefinitie pipeline is dit een unieke waarde die u later in uw pijplijnresource kunt gebruiken om te verwijzen naar de pijplijnresource. 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 is gedefinieerd om pipeline te verwijzen naar de pijplijnresource uit andere onderdelen van uw pijplijn, zoals bij het gebruik van pijplijnresourcevariabelen of het downloaden van artefacten. Zie Artefacten downloaden voor een alternatieve manier om pijplijnartefacten te downloaden.

Belangrijk

Wanneer u een pijplijnresourcetrigger definieert:

• Als de pipeline resource afkomstig is van dezelfde opslagplaats als de huidige pijplijn, of selfals het activeren dezelfde vertakking volgt en doorvoert waarop de gebeurtenis wordt gegenereerd.
• Als de pijplijnresource afkomstig is uit een andere opslagplaats, worden de huidige pijplijntriggers op de standaardbranch van de pipeline resourceopslagplaats geactiveerd.

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 de branch standaardversie omgezet wanneer de pijplijn handmatig of gepland wordt geactiveerd. De vertakkingsinvoer kan geen jokertekens hebben.

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, worden de CD-pijplijntriggers 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 op de CI-pijplijn (continue integratie) 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

Evaluatie van versieversie van pijplijnenartefact

De artefactversie van de resourcepijplijn is afhankelijk van hoe de pijplijn wordt geactiveerd.

Handmatige of geplande trigger

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	Artefactversie
version	De artefacten uit de build met het opgegeven uitvoeringsnummer
branch	De artefacten van de meest recente build die is uitgevoerd op de opgegeven vertakking
tags lijst	De artefacten uit de nieuwste build met alle opgegeven tags
branch en tags lijst	De artefacten van de meest recente build die is uitgevoerd op de opgegeven vertakking met alle opgegeven tags
Geen	De artefacten van de nieuwste build in alle vertakkingen

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 wordt uitgevoerd op de main vertakking met de Production tags.PrepProduction

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

Trigger voor voltooiing van resourcepijplijn

Wanneer een pijplijn wordt geactiveerd omdat een van de resourcepijplijnen is voltooid, is de artefactversie de versie van de triggerpijplijn. De waarden van de version, branchen tags eigenschappen worden genegeerd.

Opgegeven triggers	Resultaat
branches	Een nieuwe pijplijnuitvoering wordt geactiveerd wanneer de resourcepijplijn een uitvoering op een van de include vertakkingen heeft voltooid.
tags	Een nieuwe pijplijnuitvoering wordt geactiveerd wanneer de resourcepijplijn een uitvoering heeft voltooid met alle opgegeven tags.
stages	Er wordt een nieuwe pijplijnuitvoering geactiveerd wanneer de resourcepijplijn de opgegeven stagesuitvoering heeft uitgevoerd.
branches, en tagsstages	Een nieuwe pijplijnuitvoering wordt geactiveerd wanneer de resourcepijplijnuitvoering voldoet aan alle voorwaarden voor vertakking, tags en fasen.
trigger: true	Een nieuwe pijplijnuitvoering wordt geactiveerd wanneer de resourcepijplijn een uitvoering heeft voltooid.
Niets	Er worden geen triggers voor nieuwe pijplijnuitvoeringen geactiveerd wanneer de resourcepijplijn een uitvoering heeft voltooid.

De volgende pijplijn wordt uitgevoerd wanneer de SmartHotel-CI resourcepijplijn:

• Wordt uitgevoerd op een van de releases vertakkingen of op de main vertakking
• Is getagd met zowel Verified als Signed
• Voltooit zowel de als PreProduction de Production fasen

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

Pijplijnartefact downloaden

Met download de stap worden artefacten gedownload die zijn gekoppeld aan de huidige uitvoering of met een andere pijplijnresource.

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 overschrijven door dit in te nonestellen download of door een andere pijplijnresource-id op te geven.

Normale taakartefacten worden niet automatisch gedownload. Gebruik download deze 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)

Resourcedefinitie bouwen

Als u een extern CI-buildsysteem hebt dat artefacten produceert, kunt u artefacten builds met resources gebruiken. 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 wordt version standaard de meest recente geslaagde build gebruikt. 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 build resourceartefacten worden niet automatisch gedownload in uw taken/deploy-jobs. 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.

Resourcedefinitie van opslagplaats

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 het uitchecken voor meerdere opslagplaatsen 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 opslagplaatsen

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

• Het git type verwijst naar Git-opslagplaatsen van Azure-opslagplaatsen.
• GitHub Enterprise-opslagplaatsen vereisen een GitHub Enterprise-serviceverbinding voor autorisatie.
• Bitbucket Cloud-opslagplaatsen vereisen een Bitbucket Cloud-serviceverbinding voor autorisatie.

Type	Naamwaarde	Opmerking
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
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 uitchecken voor opslagplaatsen

Opslagplaatsen van de repository resource worden niet automatisch gesynchroniseerd in uw taken. 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.

Resourcedefinitie containers

Als u containerinstallatiekopieën als onderdeel van uw CI/CD-pijplijnen wilt gebruiken, kunt u resources gebruiken containers . Een container resource kan een openbaar of persoonlijk Docker-register of een Azure Container Registry-exemplaar zijn.

U kunt een algemene containerresource-installatiekopieën gebruiken als onderdeel van uw taak of de 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 installatiekopieën uit een Docker-register als onderdeel van uw pijplijn wilt gebruiken, kunt u een algemene containerresource 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-resourcetype

Als u uw Azure Container Registry-installatiekopieën wilt gebruiken, kunt u het resourcetype acrvan de eerste klasse container 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. Bijvoorbeeld:

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

Notitie

Serviceverbindingen die gebruikmaken van workloadidentiteitsfederatie worden niet ondersteund in azureSubscription.

Containerresourcevariabelen

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

Containerresourcevariabelen werken met Docker en Azure Container Registry. U kunt geen containerresourcevariabelen gebruiken voor lokale installatiekopieëncontainers. 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)

Resourcedefinitie pakketten

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 resources definieertpackage, geeft u de pakketopslagplaats></<naam> op in de name eigenschap en stelt u het pakket type in als NuGet ofnpm. 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 gedownload naar taken. Gebruik getPackage om te downloaden.

Het volgende voorbeeld heeft een GitHub-serviceverbinding met de naam pat-contoso een GitHub npm-pakket met de naam 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-, build- 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 binnenkomende webhookserviceverbinding een webhookgebeurtenis ontvangt, wordt er een nieuwe uitvoeringstrigger voor alle pijplijnen die zijn geabonneerd op de webhookgebeurtenis. U kunt de JSON-nettoladinggegevens in uw taken gebruiken als variabelen met behulp van de indeling ${{ parameters.<WebhookAlias>.<JSONPath>}}.

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 nettolading bevat voor aanvraagverificatie. De GitHub-aanvraagheader is X-Hub-Signaturebijvoorbeeld .

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 resourceversiekiezer wordt ondersteund voor pijplijn-, build-, opslagplaats-, container- en pakketresources.

Voor pijplijnbronnen ziet u alle beschikbare uitvoeringen in alle vertakkingen, zoekt u deze op basis van het pijplijnnummer of de vertakking en kiest u een geslaagde, mislukte of actieve uitvoering. Deze flexibiliteit zorgt ervoor dat u uw CD-pijplijn kunt uitvoeren als u zeker weet dat een uitvoering alle benodigde artefacten heeft geproduceerd. U hoeft niet te wachten totdat een CI-uitvoering is voltooid of opnieuw uitvoeren vanwege een niet-gerelateerde fasefout.

Als u de versiekiezer voor resources wilt gebruiken, selecteert u resources in het deelvenster Pijplijn uitvoeren , selecteert u vervolgens een resource en kiest u een specifieke versie in de lijst met beschikbare versies.

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.

Resourceautorisatie 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 voor resourcebeheer om alle pijplijnen toegang te geven 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 resources

U kunt goedkeuringscontroles en sjablonen gebruiken om handmatig te beheren wanneer een resource wordt uitgevoerd. Met de vereiste goedkeuringscontrole voor sjablonen kunt u vereisen dat elke pijplijn met behulp van een resource of omgeving wordt uitgebreid 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, is de resource die de pijplijn heeft geactiveerd.
• De resourceversie en de verbruikte artefacten.
• Doorvoeringen die zijn gekoppeld aan elke 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 resources die worden gebruikt als onderdeel van de implementatietaken en de bijbehorende doorvoeringen en werkitems.

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 . In de weergave ziet u alle CD YAML-pijplijnuitvoeringen die uw CI-pijplijn en de artefacten ervan hebben verbruikt.

Problemen met resourcetriggers

Resourcetriggers 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 zijn alleen beschikbaar voor niet-opslagplaatsen.

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

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 volledige zichtbaarheid in het proces door de verbruikte versie, artefacten, doorvoeringen 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 downloadgedrag in implementatietaken te overschrijven. Zie de definitie steps.download voor meer informatie.

De taak Pijplijnartefacten downloaden biedt geen traceerbaarheid of triggers, maar soms is het zinvol om deze taak rechtstreeks 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 pijplijnuitvoering activeren wanneer mijn Docker Hub-installatiekopieën worden 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 schakel de trigger voor continue implementatie in om in te schakelen. 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 pipeline 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 van 200 statuscode ontvangt, is uw webhook gereed voor gebruik door uw pijplijn.

Als u een antwoord van 500 statuscode met 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 vervolgens Bronnen ophalen.
4. Werk uw functiebranch bij onder Standaardbranch voor handmatige en geplande builds.
5. Selecteer Opslaan en wachtrij.
6. Nadat deze pijplijn is uitgevoerd, voert u 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>. U ontvangt nu een antwoord van 200 statuscode.

Gerelateerde inhoud

• Over resources voor Azure Pipelines
• Variabelen definiëren
• Variabelegroepen toevoegen en gebruiken
• Een omgeving maken en als doel gebruiken
• YAML-pijplijneditor gebruiken
• YAML schema reference (Naslag voor YAML-schema's)