Definiera resurser i YAML

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Resurser i YAML representerar källor till pipelines, byggen, lagringsplatser, containrar, paket och webhooks. Resurser ger dig också fullständig spårning av de tjänster som används i din pipeline, inklusive version, artefakter, associerade incheckningar och arbetsobjekt. När du definierar en resurs kan den användas var som helst i din pipeline. Och du kan automatisera ditt DevOps-arbetsflöde helt genom att prenumerera på för att utlösa händelser på dina resurser.

Mer information finns i Om resurser och yaml-schemadefinitionen för resurser.

Schema

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

Variabler

När en resurs utlöser en pipeline anges följande variabler:

resources.triggeringAlias
resources.triggeringCategory

Dessa värden är tomma om en resurs inte utlöser en pipelinekörning. Variabeln Build.Reason måste vara ResourceTrigger för att dessa värden ska kunna anges.

Definiera en pipelines resurs

Om du har en pipeline som producerar artefakter kan du använda artefakterna genom att definiera en pipelines resurs. pipelines är endast en dedikerad resurs för Azure Pipelines. Du kan också ange utlösare på en pipelineresurs för dina CD-arbetsflöden.

I resursdefinitionen pipeline är ett unikt värde som du kan använda för att referera till pipelineresursen senare. source är namnet på pipelinen som skapar en artefakt. Använd etiketten som definieras av pipeline för att referera till pipelineresursen från andra delar av pipelinen, till exempel när du använder pipelineresursvariabler eller laddar ned artefakter.

Ett annat sätt att ladda ned pipelines finns i uppgifterna i Pipeline Artifacts (Pipeline Artifacts).

resources:        # types: pipelines | builds | repositories | containers | packages
  pipelines:
  - pipeline: string  # identifier for the resource used in pipeline resource variables
    project: string # project for the source; optional for current project
    source: string  # name of the pipeline that produces an artifact
    version: string  # the pipeline run number to pick the artifact, defaults to latest pipeline successful across all stages; Used only for manual or scheduled triggers
    branch: string  # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
    tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
    trigger:     # triggers aren't enabled by default unless you add trigger section to the resource
      branches:  # branch conditions to filter the events, optional; Defaults to all branches.
        include: [ string ]  # branches to consider the trigger events, optional; Defaults to all branches.
        exclude: [ string ]  # branches to discard the trigger events, optional; Defaults to none.
      tags: [ string ]  # list of tags to evaluate for trigger event, optional
      stages: [ string ] # list of stages to evaluate for trigger event, optional

Viktigt!

När du definierar en resursutlösare, om dess pipelineresurs kommer från samma lagringsplats (till exempel själv) som den aktuella pipelinen, följer utlösaren samma gren och incheckning som händelsen genereras på. Men om pipelineresursen kommer från en annan lagringsplats utlöses den aktuella pipelinen på standardgrenen för självlagringsplatsen.

Utvärdering av artefaktversion

Vilken version av resurspipelinens artefakter som används beror på hur pipelinen utlöses.

Om din pipeline körs på grund av att du utlöste den manuellt eller på grund av en schemalagd körning definieras versionen av artefaktens version av värdena för versionegenskaperna , branchoch tags .

Angivna egenskaper Artefaktversion
version Artefakterna från bygget med det angivna körningsnumret
branch Artefakterna från den senaste versionen som utförts på den angivna grenen
tags Lista Artefakterna från den senaste versionen som har alla angivna taggar
branch och tags lista Artefakterna från den senaste versionen som utförts på den angivna grenen och som har alla angivna taggar
Ingen Artefakterna från den senaste versionen över alla grenar

Låt oss ta en titt på ett exempel. Anta att din pipeline innehåller följande resursdefinition.

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

När du manuellt utlöser pipelinen för körning är versionen av pipelinens MyCIAlias artefakter den senaste versionen som gjorts på grenen main och som har taggarna Production och PrepProduction .

När din pipeline utlöses på grund av att en av dess resurspipelines har slutförts är versionen av artefakterna den som utlöser pipelinen. Värdena för versionegenskaperna , branchoch tags ignoreras.

Angivna utlösare Resultat
branches En ny körning av den aktuella pipelinen utlöses när resurspipelinen slutför en körning på grenarna include
tags En ny körning av den aktuella pipelinen utlöses när resurspipelinen slutför en körning som är taggad med alla angivna taggar
stages En ny körning av den aktuella pipelinen utlöses när resurspipelinen har kört den angivna stages
branches, tags, och stages En ny körning av den aktuella pipelinen utlöses när resurspipelinekörningen uppfyller alla villkor för gren, taggar och faser
trigger: true En ny körning av den aktuella pipelinen utlöses när resurspipelinen har slutfört en körning
Ingenting Ingen ny körning av den aktuella pipelinen utlöses när resurspipelinen har slutfört en körning

Låt oss ta en titt på ett exempel. Anta att din pipeline innehåller följande resursdefinition.

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

Din pipeline körs när pipelinen SmartHotel-CI körs på en av grenarna releases eller på grenen main , taggas med både Verified och Signed, och den har slutfört både faserna Production och PreProduction .

download för pipelines

Alla artefakter från den aktuella pipelinen och från alla pipeline resurser laddas ned automatiskt och görs tillgängliga i början av varje deployment jobb. Du kan åsidosätta det här beteendet. Mer information finns i Pipelineartefakter. Vanliga "jobbartefakter" laddas inte ned automatiskt. Använd download explicit när det behövs.

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

Artefakter från resursen pipeline hämtas till $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> mappen.

Pipelineresursvariabler

I varje körning är metadata för en pipelineresurs tillgängliga för alla jobb i form av fördefinierade variabler. <Alias> är den identifierare som du gav för pipelineresursen. Pipelineresursvariabler är endast tillgängliga vid körning.

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

Mer information finns i Pipeline-resursmetadata som fördefinierade variabler.

Definiera en builds resurs

Om du har ett externt CI-byggsystem som producerar artefakter kan du använda artefakter med en builds resurs. En builds resurs kan vara alla externa CI-system som Jenkins, TeamCity, CircleCI och så vidare.

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 är en utökningsbar kategori. Du kan skriva ett tillägg för att använda artefakter från byggtjänsten och introducera en ny typ av tjänst som en del av builds. Jenkins är en typ av resurs i builds.

Viktigt!

Utlösare stöds endast för värdbaserade Jenkins där Azure DevOps har siktlinje med Jenkins-servern.

downloadBuild uppgift för byggen

Du kan använda artefakter från resursen build som en del av dina jobb med hjälp av downloadBuild uppgiften. Baserat på vilken typ av build resurs som definierats matchas den här aktiviteten automatiskt med motsvarande nedladdningsaktivitet för tjänsten under körningstiden.

Artefakter från resursen build hämtas till $(PIPELINE.WORKSPACE)/<build-identifier>/ mappen.

Viktigt!

build resursartefakter laddas inte ned automatiskt i dina jobb/distributionsjobb. Du måste uttryckligen downloadBuild lägga till uppgiften för att använda artefakterna.

- 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

Definiera en repositories resurs

Om din pipeline har mallar på en annan lagringsplats, eller om du vill använda utcheckning med flera lagringsplatser med en lagringsplats som kräver en tjänstanslutning, måste du meddela systemet om lagringsplatsen. Med nyckelordet repository kan du ange en extern lagringsplats.

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.

Typ

Pipelines stöder följande värden för lagringsplatsens typ: git, github, githubenterpriseoch bitbucket. Typen git refererar till Azure Repos Git-lagringsplatser.

Angiven typ Resultat Exempel
type: git Värdet name refererar till en annan lagringsplats i samma projekt. name: otherRepo Om du vill referera till en lagringsplats i ett annat projekt inom samma organisation prefixar du namnet med projektets namn. Ett exempel är name: OtherProject/otherRepo.
type: github Värdet name är det fullständiga namnet på GitHub-lagringsplatsen och innehåller användaren eller organisationen. name: Microsoft/vscode
type: githubenterprise värdet name är det fullständiga namnet på GitHub Enterprise-lagringsplatsen och innehåller användaren eller organisationen. name: Microsoft/vscode
type: bitbucket Värdet name är det fullständiga namnet på Bitbucket Cloud-lagringsplatsen och innehåller användaren eller organisationen. name: MyBitbucket/vscode

GitHub Enterprise-lagringsplatser kräver en GitHub Enterprise-tjänstanslutning för auktorisering.

Bitbucket Cloud-lagringsplatser kräver en Bitbucket Cloud-tjänstanslutning för auktorisering.

Variabler

I varje körning är metadata för en lagringsplatsresurs tillgängliga för alla jobb i form av körningsvariabler. <Alias> är den identifierare som du gav för lagringsplatsens resurs.

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

Variabler

I varje körning är metadata för en lagringsplatsresurs tillgängliga för alla jobb i form av körningsvariabler. <Alias> är den identifierare som du gav för lagringsplatsens resurs.

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

Använda checkout för att använda lagringsplatsen

Använd checkout nyckelord för att använda dina lagringsplatser som definierats som en del av resursen repository .

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.

Lagringsplatser från resursen repository synkroniseras inte automatiskt i dina jobb. Använd checkout för att hämta dina lagringsplatser som en del av dina jobb.

Mer information finns i Kolla in flera lagringsplatser i pipelinen.

Definiera en containers resurs

Om du behöver använda en containeravbildning som en del av ci/CD-pipelinen (kontinuerlig integrering/kontinuerlig leverans) kan du uppnå det med hjälp av containers. En containerresurs kan vara ett offentligt eller privat Docker-register eller Azure Container Registry.

Om du behöver använda avbildningar från Docker-registret som en del av pipelinen kan du definiera en allmän containerresurs (inte type nyckelord krävs).

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

Du kan använda en allmän containerresurs som en avbildning som används som en del av jobbet, eller också kan den användas för containerjobb. Om din pipeline kräver stöd för en eller flera tjänster vill du skapa och ansluta till tjänstcontainrar. Du kan använda volymer för att dela data mellan tjänster.

Du kan använda en förstklassig containerresurstyp för Azure Container Registry (ACR) för att använda dina ACR-avbildningar. Den här resurstypen kan användas som en del av dina jobb och även för att aktivera automatiska pipelineutlösare. Du måste ha behörigheten Deltagare eller Ägare för att ACR ska kunna använda automatiska pipelineutlösare. Mer information finns i Roller och behörigheter för Azure Container Registry.

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

Kommentar

Syntaxen som används för att aktivera containerutlösare för alla avbildningstaggar (enabled: 'true') skiljer sig från syntaxen som används för andra resursutlösare. Var noga med att använda rätt syntax för en specifik resurs.

Kommentar

Tjänstanslutningar som använder arbetsbelastningsidentitetsfederation stöds inte i azureSubscription.

Containerresursvariabler

När du har definierat en container som en resurs skickas metadata för containeravbildningar till pipelinen i form av variabler. Information som avbildning, register och anslutningsinformation är tillgänglig för alla jobb som ska användas i dina containerdistributionsuppgifter.

Containerresursvariabler fungerar med Docker och Azure Container Registry. Du kan inte använda containerresursvariabler för lokala avbildningscontainrar.

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

Platsvariabeln gäller endast för ACR typ av containerresurser.

Definiera en packages resurs

Du kan använda NuGet- och npm GitHub-paket som en resurs i YAML-pipelines.

När du anger package resurser anger du paketet som NuGet eller npm. Du kan också aktivera automatiserade pipelineutlösare när en ny paketversion släpps.

Om du vill använda GitHub-paket använder du personlig åtkomsttoken (PAT)-baserad autentisering och skapar en GitHub-tjänstanslutning som använder PAT.

Som standard laddas paket inte ned automatiskt till jobb. Om du vill ladda ned använder du 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

Definiera en webhooks resurs

Kommentar

Webhooks släpptes i Azure DevOps Server 2020.1.

Med andra resurser (till exempel pipelines, containrar, versioner och paket) kan du använda artefakter och aktivera automatiserade utlösare. Du kan emellertid inte automatisera distributionsprocessen baserat på andra externa händelser eller tjänster. Med resursen webhooks kan du integrera din pipeline med valfri extern tjänst och automatisera arbetsflödet. Du kan prenumerera på externa händelser via dess webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory och så vidare) och utlösa dina pipelines.

Utför följande steg för att konfigurera webhooksutlösare.

  1. Konfigurera en webhook på den externa tjänsten. När du skapar webhooken måste du ange följande information:

    • Url för begäran

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

    • Hemlighet – valfritt. Om du behöver skydda din JSON-nyttolast anger du värdet Hemlighet .

  2. Skapa en ny tjänstanslutning för inkommande webhook. Denna anslutning är en nyligen introducerad tjänstanslutningstyp som gör att du kan definiera följande viktiga information:

    • Webhook-namn: Namnet på webhooken ska matcha webhooken som skapats i den externa tjänsten.
    • HTTP-huvud – namnet på HTTP-huvudet i begäran som innehåller nyttolastens HMAC-SHA1-hashvärde för verifiering av begäran. För GitHub är till exempel begärandehuvudet "X-Hub-Signature".
    • Hemlighet – Hemligheten används för att verifiera nyttolastens HMAC-SHA1-hash som används för verifiering av den inkommande begäran (valfritt). Om du använde en hemlighet när du skapade webhooken måste du ange samma hemliga nyckel.

    Incoming Webhook Service connection

  3. En ny resurstyp med namnet webhooks introduceras i YAML-pipelines. Om du vill prenumerera på en webhook-händelse definierar du en webhook-resurs i pipelinen och pekar den på inkommande webhook-tjänstanslutning. Du kan också definiera fler filter på webhook-resursen, baserat på JSON-nyttolastdata, för att anpassa utlösarna för varje pipeline. Använd nyttolastdata i form av variabler i dina jobb.

  4. När den inkommande Webhook-tjänstanslutningen tar emot en webhook-händelse utlöses en ny körning för alla pipelines som prenumererar på webhook-händelsen. Du kan använda JSON-nyttolastdata i dina jobb med hjälp av formatet ${{ 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 automatiserar arbetsflödet baserat på alla externa webhook-händelser som inte stöds av förstklassiga resurser, till exempel pipelines, byggen, containrar och paket. För lokala tjänster där Azure DevOps inte har insyn i processen kan du också konfigurera webhooks på tjänsten och utlösa dina pipelines automatiskt.

Manuell versionsväljare för resurser i dialogrutan skapa körning

När du manuellt utlöser en CD YAML-pipeline utvärderar vi automatiskt standardversionen för de resurser som definierats i pipelinen baserat på de indata som tillhandahålls. Du kan dock välja att välja en annan version än resursversionsväljaren när du skapar en körning.

  1. I fönstret Skapa körning väljer du Resurser. Du ser en lista över resurser som förbrukas i den här pipelinen.

  2. Välj en resurs och välj en specifik version i listan över tillgängliga versioner. Resursversionsväljaren stöds för pipeline-, bygg-, lagringsplats-, container- och paketresurser.

    Pipeline Version Picker

För pipelineresurser kan du se alla tillgängliga körningar över alla grenar. Sök efter dem baserat på pipelinenumret eller grenen. Och välj en körning som är lyckad, misslyckad eller pågår. Den här flexibiliteten säkerställer att du kan köra cd-pipelinen om du är säker på att den har skapat alla artefakter som du behöver. Du behöver inte vänta tills CI-körningen har slutförts eller körts på nytt på grund av ett orelaterat fasfel i CI-körningen. Vi kan dock bara överväga att slutföra CI-körningar när vi utvärderar standardversionen för schemalagda utlösare, eller om du inte använder manuell versionsväljare.

För resurser där du inte kan hämta tillgängliga versioner, till exempel GitHub-paket, visar vi en textruta som en del av versionsväljaren så att du kan ange den version som körningen ska välja.

Auktorisera en YAML-pipeline

Resurser måste auktoriseras innan de kan användas. En resursägare styr de användare och pipelines som kan komma åt resursen. Pipelinen måste ha behörighet att använda resursen. Se följande sätt att auktorisera en YAML-pipeline.

  • Gå till administrationsupplevelsen för resursen. Till exempel hanteras variabelgrupper och säkra filer på sidan Bibliotek under Pipelines. Agentpooler och tjänstanslutningar hanteras i Projektinställningar. Här kan du auktorisera alla pipelines för åtkomst till den resursen. Den här auktoriseringen är praktisk om du inte behöver begränsa åtkomsten till en resurs , till exempel testresurser.

  • När du skapar en pipeline för första gången godkänns alla resurser som refereras i YAML-filen automatiskt för användning av pipelinen, om du är medlem i användarrollen för den resursen. Därför auktoriseras resurser som refereras i YAML-filen när du skapar en pipeline automatiskt.

  • När du gör ändringar i YAML-filen och lägger till resurser misslyckas bygget med ett fel som liknar följande fel: Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.

    I det här fallet visas ett alternativ för att auktorisera resurserna i den misslyckade versionen. Om du är medlem i resursens användarroll kan du välja det här alternativet. När resurserna har auktoriserats kan du starta en ny version.

  • Kontrollera att agentpoolens säkerhetsroller för projektet är korrekta.

Ange godkännandekontroller för resurser

Du kan manuellt styra när en resurs körs med godkännandekontroller och mallar. Med den nödvändiga godkännandekontrollen för mallar kan du kräva att alla pipelines med hjälp av en resurs eller miljö också utökas från en specifik YAML-mall. Att ange ett obligatoriskt mallgodkännande förbättrar säkerheten. Se till att din resurs endast används under specifika villkor med en mall. Läs mer om hur du förbättrar pipelinesäkerheten med mallar och resurser.

Spårbarhet

Vi tillhandahåller fullständig spårbarhet för alla resurser som förbrukas på en pipeline- eller distributionsjobbnivå.

Pipelinespårning

För varje pipelinekörning visar vi följande information.

  • Resursen som har utlöst pipelinen, om den utlöses av en resurs.

    Resource trigger in a pipeline

  • Version av resursen och de artefakter som används.

    Consumed artifacts in pipeline run

  • Incheckningar som är associerade med varje resurs.

    Commits in pipeline run

  • Arbetsobjekt som är associerade med varje resurs.

Miljöspårbarhet

När en pipeline distribueras till en miljö kan du se en lista över resurser som förbrukas. I följande vy ingår resurser som förbrukas som en del av distributionsjobben och tillhörande incheckningar och arbetsobjekt.

Commits in environment

Visa information om associerade CD-pipelines i CI-pipelines

För att tillhandahålla spårbarhet från slutpunkt till slutpunkt kan du spåra vilka CD-pipelines som använder en givande CI-pipeline. Du kan se listan över CD YAML-pipelines som körs där en CI-pipelinekörning används via resursen pipeline . Om andra pipelines använder din CI-pipeline visas fliken "Associerade pipelines" i körningsvyn. Här hittar du alla pipelinekörningar som förbrukar din pipeline och artefakter från den.

CD pipelines information in CI pipeline

Stöd och spårning av YAML-resursutlösare

Det kan vara förvirrande när pipelineutlösare inte kan köras. Vi har lagt till ett nytt menyalternativ på pipelinedefinitionssidan med namnet Utlösarproblem, där du kan lära dig varför utlösare inte körs. Öppna pipelinehistoriken om du vill komma åt den här sidan. Utlösarproblem är endast tillgängligt för resurser som inte är lagringsplatser.

Select Trigger Issues from the navigation.

Resursutlösare kan inte köras av följande skäl.

  • Om källan för tjänstanslutningen som tillhandahålls är ogiltig, eller om det finns syntaxfel i utlösaren, är utlösaren inte konfigurerad, vilket resulterar i ett fel.

  • Om utlösarvillkoren inte matchas körs inte utlösaren. En varning visas så att du kan förstå varför villkoren inte matchades.

    Trigger issues supportability

Nästa steg

Lägga till och använda variabelgrupper

Vanliga frågor

Varför ska jag använda pipelines resources i stället för download genvägen?

Att använda en pipelines resurs är ett sätt att använda artefakter från en CI-pipeline och även konfigurera automatiserade utlösare. En resurs ger dig fullständig insyn i processen genom att visa den version som används, artefakter, incheckningar och arbetsobjekt. När du definierar en pipelineresurs hämtas de associerade artefakterna automatiskt i distributionsjobb.

Du kan välja att ladda ned artefakterna i byggjobb eller åsidosätta nedladdningsbeteendet i distributionsjobb med download. Mer information finns i steps.download.

Varför ska jag använda resources i stället för uppgiften Ladda ned pipelineartefakter?

När du använder uppgiften Ladda ned pipelineartefakter direkt missar du spårbarhet och utlösare. Ibland är det klokt att använda uppgiften Ladda ned pipelineartefakter direkt. Du kan till exempel ha en skriptuppgift lagrad i en annan mall och skriptaktiviteten kräver att artefakter från en version laddas ned. Eller så kanske du inte vet om någon som använder en mall vill lägga till en pipelineresurs. För att undvika beroenden kan du använda uppgiften Ladda ned pipelineartefakter för att skicka all bygginformation till en uppgift.

Hur utlöser jag en pipelinekörning när min Docker Hub-avbildning uppdateras?

Du måste konfigurera en klassisk versionspipeline eftersom containerresursutlösaren inte är tillgänglig för Docker Hub för YAML-pipelines.

  1. Skapa en ny Docker Hub-tjänstanslutning.

  2. Skapa en klassisk versionspipeline och lägg till en Docker Hub-artefakt. Ange tjänstanslutningen. Välj namnrymd, lagringsplats, version och källalias.

    Add a Docker Hub artifact.

  3. Välj utlösaren och växla den kontinuerliga distributionsutlösaren till Aktivera. Du skapar en version varje gång en Docker-push sker till den valda lagringsplatsen.

  4. Skapa en ny fas och ett nytt jobb. Lägg till två uppgifter, Docker-inloggning och Bash:

  • Docker-aktiviteten har åtgärden login och loggar in dig på Docker Hub.

  • Bash-aktiviteten kör docker pull <hub-user>/<repo-name>[:<tag>]. Ersätt hub-user, repo-nameoch tag med dina värden.

    Add Docker login and Bash tasks.

Hur kan jag verifiera och felsöka webhooks?

  1. Skapa en tjänstanslutning.

  2. Referera till tjänstanslutningen och ge webhooken namnet i avsnittet webhooks .

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. Kör din pipeline. När du kör din pipeline skapas webhooken i Azure som en distribuerad uppgift för din organisation.

  4. Utför ett POST API-anrop med giltig JSON i brödtexten till https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Om du får ett 200-statuskodsvar är webhooken redo att användas av din pipeline. Om du får ett 500-statuskodsvar med felet Cannot find webhook for the given webHookId ...kan koden finnas i en gren som inte är standardgrenen.

    1. Öppna pipelinen.
    2. Välj Redigera.
    3. Välj menyn Select more actions menu Fler åtgärder .
    4. Välj Utlösare>YAML>Hämta källor.
    5. Gå till Standardgren för manuella och schemalagda versioner för att uppdatera funktionsgrenen .
    6. Välj Spara och kö.
    7. När pipelinen har körts utför du ett POST API-anrop med giltig JSON i brödtexten till https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Nu bör du få ett 200-statuskodsvar.