Resources definiëren in YAML

  • Artikel

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

Resources in YAML vertegenwoordigen bronnen van pijplijnen, builds, opslagplaatsen, containers, pakketten en webhooks. Resources bieden u ook de volledige traceerbaarheid van de services die in uw pijplijn worden gebruikt, waaronder de versie, artefacten, gekoppelde doorvoeringen en werkitems. Wanneer u een resource definieert, kan deze overal in uw pijplijn worden gebruikt. En u kunt uw DevOps-werkstroom volledig automatiseren door u te abonneren op het activeren van gebeurtenissen in uw resources.

Zie Informatie over resources en de YAML-schemadefinitie voor resources voor meer informatie.

Schema

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

Variabelen

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

resources.triggeringAlias
resources.triggeringCategory

Deze waarden zijn leeg als een resource geen pijplijnuitvoering activeert. De variabele Build.Reason moet zijn ResourceTrigger voor deze waarden om deze waarden in te stellen.

pipelines Een resource definiëren

Als u een pijplijn hebt die artefacten produceert, kunt u de artefacten gebruiken door een pipelines resource te definiëren. pipelines is alleen een toegewezen resource voor Azure Pipelines. U kunt ook triggers instellen voor een pijplijnresource voor uw CD-werkstromen.

In uw resourcedefinitie pipeline is dit een unieke waarde die u later kunt gebruiken om te verwijzen naar de pijplijnresource. source is de naam van de pijplijn die een artefact produceert. Gebruik het label dat is gedefinieerd om pipeline te verwijzen naar de pijplijnresource uit andere onderdelen van de pijplijn, zoals bij het gebruik van pijplijnresourcevariabelen of het downloaden van artefacten.

Zie de taken in Pijplijnartefacten voor een alternatieve manier om pijplijnen te downloaden.

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. If it is in a different pipelines folder, it needs to be the full path, e.g. MyTeam/MyPipeline
    version: string  # the pipeline run number (Build.BuildNumber) to pick the artifact, defaults to latest pipeline successful run 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 for 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

Belangrijk

Wanneer u een resourcetrigger definieert en de pijplijnresource afkomstig is van dezelfde opslagplaats (bijvoorbeeld zelf) als de huidige pijplijn, volgt triggering dezelfde vertakking en doorvoer waarop de gebeurtenis wordt gegenereerd. Maar als de pijplijnresource afkomstig is uit een andere opslagplaats, wordt de huidige pijplijn geactiveerd op de standaardbranch van de zelfopslagplaats.

Evaluatie van artefactversie

De versie van de artefacten van de resourcepijplijn is afhankelijk van hoe uw pijplijn wordt geactiveerd.

Als uw pijplijn wordt uitgevoerd omdat u deze handmatig hebt geactiveerd of vanwege een geplande uitvoering, wordt de versie van artefactversie gedefinieerd door de waarden van de version, branchen tags eigenschappen.

Opgegeven eigenschappen Artefactversie
version De artefacten uit de build met het opgegeven uitvoeringsnummer
branch De artefacten van de nieuwste build die op de opgegeven vertakking zijn uitgevoerd
tags Lijst De artefacten uit de nieuwste build met alle opgegeven tags
branch en tags lijst De artefacten uit de meest recente build die op de opgegeven vertakking zijn uitgevoerd en die alle opgegeven tags bevatten
Geen De artefacten van de nieuwste build in alle vertakkingen

We kijken naar een voorbeeld. Stel dat uw pijplijn de volgende resourcedefinitie bevat.

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

Wanneer u de pijplijn handmatig activeert om uit te voeren, is de versie van de artefacten van de MyCIAlias pijplijn een van de nieuwste build die is uitgevoerd op de main vertakking en die de Production en PrepProduction tags bevat.

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

Opgegeven triggers Resultaat
branches Er wordt een nieuwe uitvoering van de huidige pijplijn geactiveerd wanneer de resourcepijplijn een uitvoering op de include vertakkingen heeft voltooid
tags Er wordt een nieuwe uitvoering van de huidige pijplijn geactiveerd wanneer de resourcepijplijn een uitvoering heeft voltooid die is gelabeld met alle opgegeven tags
stages Er wordt een nieuwe uitvoering van de huidige pijplijn geactiveerd wanneer de resourcepijplijn de opgegeven stages
branches, en tagsstages Er wordt een nieuwe uitvoering van de huidige pijplijn geactiveerd wanneer de resourcepijplijnuitvoering voldoet aan alle voorwaarden voor vertakking, tags en fasen
trigger: true Een nieuwe uitvoering van de huidige pijplijn wordt geactiveerd wanneer de resourcepijplijn een uitvoering heeft voltooid
Niets Er wordt geen nieuwe uitvoering van de huidige pijplijn geactiveerd wanneer de resourcepijplijn een uitvoering heeft voltooid

We kijken naar een voorbeeld. Stel dat uw pijplijn de volgende resourcedefinitie bevat.

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

Uw pijplijn wordt uitgevoerd wanneer de SmartHotel-CI pijplijn wordt uitgevoerd op een van de releases vertakkingen of op de main vertakking, wordt getagd met beide Verified en Signed, en het heeft zowel de als de ProductionPreProduction fasen voltooid.

download voor pijplijnen

Alle artefacten uit de huidige pijplijn en van alle pipeline resources worden automatisch gedownload en beschikbaar gemaakt aan het begin van elke deployment taak. U kunt dit gedrag negeren. Zie Pijplijnartefacten voor meer informatie. Normale taakartefacten worden niet automatisch gedownload. Gebruik download deze expliciet wanneer dat nodig is.

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

Artefacten van de resource worden gedownload naar $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> de pipeline map.

Pijplijnresourcevariabelen

In elke uitvoering zijn de metagegevens voor een pijplijnresource beschikbaar voor alle taken in de vorm van vooraf gedefinieerde variabelen. Dit <Alias> is de id die u hebt opgegeven voor uw pijplijnresource. Variabelen voor pijplijnbronnen zijn alleen beschikbaar tijdens runtime.

Zie Variabelen definiëren voor meer informatie over de syntaxis van variabelen.

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

Zie Metagegevens van pijplijnresources als vooraf gedefinieerde variabelen voor meer informatie.

builds Een resource definiëren

Als u een extern CI-buildsysteem hebt dat artefacten produceert, kunt u artefacten met een builds resource gebruiken. Een builds resource kan externe CI-systemen zijn, zoals Jenkins, TeamCity, CircleCI, enzovoort.

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 is een uitbreidbare categorie. U kunt een extensie schrijven om artefacten van uw builds-service te gebruiken en een nieuw type service te introduceren als onderdeel van builds. Jenkins is een type resource in builds.

Belangrijk

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

downloadBuild taak voor builds

U kunt artefacten van de build resource gebruiken als onderdeel van uw taken met behulp van de downloadBuild taak. Op basis van build het type resource dat is gedefinieerd, wordt deze taak automatisch omgezet in de bijbehorende downloadtaak voor de service tijdens de runtime.

Artefacten van de resource worden gedownload naar $(PIPELINE.WORKSPACE)/<build-identifier>/ de build map.

Belangrijk

build resourceartefacten worden niet automatisch gedownload in uw taken/deploy-jobs. U moet de taak expliciet toevoegen voor het downloadBuild gebruik van de artefacten.

- 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

repositories Een resource definiëren

Als uw pijplijn sjablonen in een andere opslagplaats bevat of als u het uitchecken van meerdere opslagplaatsen wilt gebruiken met een opslagplaats waarvoor een serviceverbinding is vereist, moet u het systeem op de hoogte stellen van die opslagplaats. Met repository het trefwoord kunt u een externe opslagplaats opgeven.

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

Type

Pijplijnen ondersteunen de volgende waarden voor het type opslagplaats: git, github, githubenterpriseen bitbucket. Het git type verwijst naar Git-opslagplaatsen van Azure-opslagplaatsen.

Type opgegeven Resultaat Opmerking
type: git De name waarde verwijst naar een andere opslagplaats in hetzelfde project. name: otherRepo Als u wilt verwijzen naar een opslagplaats in een ander project binnen dezelfde organisatie, moet u de naam vooraf laten gaan aan de naam van dat project. Een voorbeeld is name: OtherProject/otherRepo.
type: github De name waarde is de volledige naam van de GitHub-opslagplaats en bevat de gebruiker of organisatie. name: Microsoft/vscode
type: githubenterprise de name waarde is de volledige naam van de GitHub Enterprise-opslagplaats en bevat de gebruiker of organisatie. name: Microsoft/vscode
type: bitbucket De name waarde is de volledige naam van de Bitbucket Cloud-opslagplaats en bevat de gebruiker of organisatie. name: MyBitbucket/vscode

GitHub Enterprise-opslagplaatsen vereisen een GitHub Enterprise-serviceverbinding voor autorisatie.

Bitbucket Cloud-opslagplaatsen vereisen een Bitbucket Cloud-serviceverbinding voor autorisatie.

Variabelen

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

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

Variabelen

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

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

Gebruiken checkout om opslagplaats te gebruiken

Gebruik checkout het trefwoord om uw opslagplaatsen te gebruiken die zijn gedefinieerd als onderdeel van repository de resource.

Schema

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

Opslagplaatsen van de repository resource worden niet automatisch gesynchroniseerd in uw taken. Gebruik checkout dit om uw opslagplaatsen op te halen als onderdeel van uw taken.

Zie Meerdere opslagplaatsen in uw pijplijn bekijken voor meer informatie.

containers Een resource definiëren

Als u een containerinstallatiekopieën wilt gebruiken als onderdeel van uw CI/CD-pijplijn (continuous integration/continuous delivery), kunt u deze bereiken met behulp van containers. Een containerresource kan een openbaar of persoonlijk Docker Registry of Azure Container Registry zijn.

Als u installatiekopieën uit het Docker-register wilt gebruiken als onderdeel van uw pijplijn, kunt u een algemene containerresource definiëren (niet type vereist voor trefwoorden).

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

U kunt een algemene containerresource gebruiken als een installatiekopieën die worden gebruikt als onderdeel van uw taak of kunnen ook worden gebruikt 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.

U kunt een eerste klasse containerresourcetype voor Azure Container Registry (ACR) gebruiken om uw ACR-installatiekopieën te gebruiken. Dit type resources kan worden gebruikt als onderdeel van uw taken en kan ook automatische pijplijntriggers inschakelen. U moet inzender- of eigenaarmachtigingen hebben voor ACR om automatische pijplijntriggers te kunnen gebruiken. Zie Azure Container Registry-rollen en -machtigingen voor meer informatie.

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

Notitie

De syntaxis die wordt gebruikt om containertriggers in te schakelen voor alle afbeeldingstags (enabled: 'true') verschilt van de syntaxis die wordt gebruikt voor andere resourcetriggers. Let goed op het gebruik van de juiste syntaxis voor een specifieke resource.

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 doorgegeven aan de pijplijn in de vorm van variabelen. Informatie zoals installatiekopieën, registers en verbindingsgegevens zijn toegankelijk voor alle taken die moeten worden gebruikt in uw container-implementatietaken.

Containerresourcevariabelen werken met Docker en Azure Container Registry. U kunt geen containerresourcevariabelen gebruiken voor lokale installatiekopieëncontainers.

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

Locatievariabele is alleen van toepassing op ACR het type containerbronnen.

packages Een resource definiëren

U kunt NuGet- en NPM GitHub-pakketten gebruiken als een resource in YAML-pijplijnen.

Wanneer u resources opgeeft package , stelt u het pakket in als NuGet of npm. U kunt ook geautomatiseerde pijplijntriggers inschakelen wanneer een nieuwe pakketversie wordt uitgebracht.

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 PAT's.

Pakketten worden standaard niet automatisch gedownload naar taken. Als u wilt downloaden, gebruikt u getPackage.

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

webhooks Een resource definiëren

Notitie

Webhooks zijn uitgebracht in Azure DevOps Server 2020.1.

Met andere resources (zoals pijplijnen, containers, builds en pakketten) kunt u artefacten gebruiken en geautomatiseerde triggers inschakelen. U kunt uw implementatieproces echter niet automatiseren op basis van andere externe gebeurtenissen of services. Met webhooks de resource kunt u uw pijplijn integreren met elke externe service en de werkstroom automatiseren. U kunt zich abonneren op externe gebeurtenissen via de webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory, enzovoort) en uw pijplijnen activeren.

Volg de volgende stappen om de webhooktriggers te configureren.

  1. Stel een webhook in uw externe service in. Wanneer u uw webhook maakt, moet u de volgende informatie opgeven:

    • Aanvraag-URL

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

    • Geheim - optioneel. Als u uw JSON-nettolading wilt beveiligen, geeft u de geheime waarde op.

  2. Maak een nieuwe serviceverbinding voor binnenkomende webhook. Deze verbinding is een nieuw geïntroduceerd serviceverbindingstype waarmee u de volgende belangrijke informatie kunt definiëren:

    • Webhooknaam: de naam van de webhook moet overeenkomen met de webhook die is gemaakt in uw externe service.
    • HTTP-header : de naam van de HTTP-header in de aanvraag die de HMAC-SHA1-hashwaarde van de nettolading bevat voor aanvraagverificatie. Voor GitHub is de aanvraagheader bijvoorbeeld 'X-Hub-Signature'.
    • Geheim : het geheim wordt gebruikt om de HMAC-SHA1-hash van de nettolading te verifiëren die wordt gebruikt voor verificatie van de binnenkomende aanvraag (optioneel). Als u een geheim hebt gebruikt bij het maken van uw webhook, moet u dezelfde geheime sleutel opgeven.

    Binnenkomende webhookserviceverbinding

  3. Er wordt een nieuw resourcetype aangeroepen webhooks in YAML-pijplijnen. Als u zich wilt abonneren op een webhook-gebeurtenis, definieert u een webhookresource in uw pijplijn en wijst u deze aan op de inkomende 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. Verbruik de nettoladinggegevens in de vorm van variabelen in uw taken.

  4. Wanneer de inkomende webhookserviceverbinding een webhookgebeurtenis ontvangt, wordt een nieuwe uitvoering geactiveerd voor alle pijplijnen die zijn geabonneerd op de webhookgebeurtenis. U kunt de JSON-nettoladinggegevens in uw taken gebruiken met behulp van de indeling ${{ 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 automatiseren uw werkstroom op basis van een externe webhook-gebeurtenis die niet wordt ondersteund door resources van de eerste klasse, zoals pijplijnen, builds, containers en pakketten. Voor on-premises services waarvoor Azure DevOps geen inzicht heeft in het proces, kunt u webhooks op de service configureren en uw pijplijnen automatisch activeren.

Handmatige versiekiezer voor resources in het dialoogvenster Uitvoeren maken

Wanneer u handmatig een CD YAML-pijplijn activeert, evalueren we automatisch de standaardversie voor de resources die in de pijplijn zijn gedefinieerd, op basis van de opgegeven invoer. U kunt er echter voor kiezen om een andere versie te kiezen dan de resourceversiekiezer wanneer u een uitvoering maakt.

  1. Selecteer Resources in het deelvenster Uitvoeren maken. U ziet een lijst met resources die in deze pijplijn worden gebruikt.

  2. Selecteer een resource en kies een specifieke versie in de lijst met beschikbare versies. Resourceversiekiezer wordt ondersteund voor pijplijn-, build-, opslagplaats-, container- en pakketresources.

    Pijplijnversiekiezer

Voor pijplijnbronnen ziet u alle beschikbare uitvoeringen in alle vertakkingen. Zoek ze op basis van het pijplijnnummer of de vertakking. En kies een uitvoering die is geslaagd, mislukt of wordt uitgevoerd. Deze flexibiliteit zorgt ervoor dat u uw CD-pijplijn kunt uitvoeren als u zeker weet dat deze alle artefacten heeft geproduceerd die u nodig hebt. U hoeft niet te wachten totdat de CI-uitvoering is voltooid of opnieuw wordt uitgevoerd vanwege een niet-gerelateerde fasefout in de CI-uitvoering. We beschouwen echter alleen voltooide CI-uitvoeringen wanneer we de standaardversie voor geplande triggers evalueren of als u geen handmatige versiekiezer gebruikt.

Voor resources waar u geen beschikbare versies kunt ophalen, zoals GitHub-pakketten, wordt een tekstvak weergegeven als onderdeel van de versiekiezer, zodat u de versie voor de uitvoering kunt opgeven die u kunt kiezen.

Een YAML-pijplijn autoriseren

Resources moeten worden geautoriseerd voordat ze kunnen worden gebruikt. Een resource-eigenaar bepaalt de gebruikers en pijplijnen die toegang hebben tot die resource. De pijplijn moet zijn geautoriseerd om de resource te kunnen gebruiken. Bekijk de volgende manieren waarop u een YAML-pijplijn kunt autoriseren.

  • Ga naar de beheerervaring van de resource. Variabele groepen en beveiligde bestanden worden bijvoorbeeld beheerd op de pagina Bibliotheek onder Pijplijnen. Agentpools en serviceverbindingen worden beheerd in Project-instellingen. Hier kunt u alle pijplijnen autoriseren voor toegang tot die resource. Deze autorisatie is handig als u de toegang tot een resource niet hoeft te beperken, bijvoorbeeld om resources te testen.

  • Wanneer u voor het eerst een pijplijn maakt, worden alle resources waarnaar wordt verwezen in het YAML-bestand automatisch geautoriseerd voor gebruik door de pijplijn als u lid bent van de gebruikersrol voor die resource. Resources waarnaar wordt verwezen in het YAML-bestand wanneer u een pijplijn maakt, worden dus automatisch geautoriseerd.

  • Wanneer u wijzigingen aanbrengt in het YAML-bestand en resources toevoegt, mislukt de build met een fout die vergelijkbaar is met de volgende fout: Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.

    In dit geval ziet u een optie voor het autoriseren van de resources voor de mislukte build. Als u lid bent van de gebruikersrol voor de resource, kunt u deze optie selecteren. Zodra de resources zijn geautoriseerd, kunt u een nieuwe build starten.

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

Goedkeuringscontroles instellen voor resources

U kunt handmatig bepalen wanneer een resource wordt uitgevoerd met goedkeuringscontroles en sjablonen. Met de vereiste goedkeuringscontrole voor sjablonen kunt u elke pijplijn met behulp van een resource of omgeving ook uitbreiden van een specifieke YAML-sjabloon. Het instellen van een vereiste sjabloongoedkeuring verbetert de beveiliging. Zorg ervoor dat uw resource alleen wordt gebruikt onder specifieke voorwaarden met een sjabloon. Meer informatie over het verbeteren van de beveiliging van pijplijnen met sjablonen en resources.

Traceerbaarheid

We bieden volledige traceerbaarheid voor alle resources die worden gebruikt op pijplijn- of implementatietaakniveau.

Traceerbaarheid van pijplijnen

Voor elke pijplijnuitvoering geven we de volgende informatie weer.

  • De resource die de pijplijn heeft geactiveerd, als deze wordt geactiveerd door een resource.

    Resourcetrigger in een pijplijn

  • Versie van de resource en de verbruikte artefacten.

    Verbruikte artefacten in pijplijnuitvoering

  • Doorvoeringen die zijn gekoppeld aan elke resource.

    Doorvoeringen in pijplijnuitvoering

  • 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 volgende weergave bevat resources die worden gebruikt als onderdeel van de implementatietaken en de bijbehorende doorvoeringen en werkitems.

Doorvoeringen in omgeving

Informatie over gekoppelde CD-pijplijnen weergeven in CI-pijplijnen

Als u end-to-end traceerbaarheid wilt bieden, kunt u bijhouden welke CD-pijplijnen een gevende CI-pijplijn gebruiken. U kunt de lijst met CD YAML-pijplijnen zien waarop een CI-pijplijnuitvoering wordt gebruikt via de pipeline resource. Als andere pijplijnen uw CI-pijplijn gebruiken, ziet u het tabblad Gekoppelde pijplijnen in de uitvoeringsweergave. Hier vindt u alle pijplijnuitvoeringen die uw pijplijn en artefacten ervan verbruiken.

Informatie over CD-pijplijnen in CI-pijplijn

Problemen met YAML-resourcetriggers ondersteunen en traceerbaarheid

Het kan verwarrend zijn wanneer pijplijntriggers niet kunnen worden uitgevoerd. We hebben een nieuw menu-item toegevoegd op de pagina pijplijndefinitie met de naam Triggerproblemen, waar u kunt zien waarom triggers niet worden uitgevoerd. Open uw pijplijngeschiedenis om deze pagina te openen. Triggerproblemen zijn alleen beschikbaar voor niet-opslagplaatsresources.

Selecteer Triggerproblemen in de navigatie.

Resourcetriggers kunnen om de volgende redenen niet worden uitgevoerd.

  • Als de bron van de opgegeven serviceverbinding ongeldig is of als er syntaxisfouten in de trigger zijn, wordt de trigger niet geconfigureerd, wat resulteert in een fout.

  • Als de triggervoorwaarden niet overeenkomen, wordt de trigger niet uitgevoerd. Er wordt een waarschuwing weergegeven, zodat u kunt begrijpen waarom de voorwaarden niet overeenkomen.

    Ondersteuningsproblemen activeren

Volgende stappen

Variabelegroepen toevoegen en gebruiken

Veelgestelde vragen

Waarom moet ik pijplijnen resources gebruiken in plaats van de download snelkoppeling?

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 ervoor kiezen om de artefacten in buildtaken te downloaden of om het downloadgedrag in implementatietaken downloadmet te overschrijven. Zie steps.download voor meer informatie.

Waarom moet ik in plaats van de taak Pijplijnartefacten downloaden gebruiken resources ?

Wanneer u de taak Pijplijnartefacten downloaden rechtstreeks gebruikt, mist u traceerbaarheid en triggers. Soms is het zinvol om de taak Pijplijnartefacten downloaden rechtstreeks te gebruiken. U hebt bijvoorbeeld een scripttaak opgeslagen in een andere sjabloon en voor de scripttaak moeten artefacten uit een build worden gedownload. Of misschien weet u niet of iemand die een sjabloon gebruikt, een pijplijnresource wil toevoegen. 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?

U moet een klassieke release-pijplijn instellen omdat de resourcetrigger voor containers niet beschikbaar is voor Docker Hub voor YAML-pijplijnen.

  1. Maak een nieuwe Docker Hub-serviceverbinding.

  2. Maak een klassieke release-pijplijn en voeg een Docker Hub-artefact toe. Stel uw serviceverbinding in. Selecteer de naamruimte, opslagplaats, versie en bronalias.

    Een Docker Hub-artefact toevoegen.

  3. Selecteer de trigger en schakel de trigger voor continue implementatie in om in te schakelen. U maakt een release telkens wanneer een Docker-push plaatsvindt naar de geselecteerde opslagplaats.

  4. Maak een nieuwe fase en taak. Voeg twee taken toe, Docker-aanmelding en Bash:

  • De Docker-taak heeft de login actie en registreert u in Docker Hub.

  • De Bash-taak wordt uitgevoerd docker pull <hub-user>/<repo-name>[:<tag>]. Vervang hub-user, repo-nameen tag door uw waarden.

    Docker-aanmeldings- en Bash-taken toevoegen.

Hoe kan ik webhooks 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. Wanneer u uw pijplijn uitvoert, wordt de webhook 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.

    1. Open uw pijplijn.
    2. Selecteer Bewerken.
    3. Selecteer het menu Menu Meer acties selecteren meer acties.
    4. Selecteer YAML-bronnen> ophalen voor triggers.>
    5. Ga naar de standaardbranch voor handmatige en geplande builds om uw functiebranch bij te werken.
    6. Selecteer Opslaan en wachtrij.
    7. 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.