Definire le risorse in YAML

  • Articolo

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

Le risorse in YAML rappresentano origini di pipeline, compilazioni, repository, contenitori, pacchetti e webhook. Le risorse offrono anche la tracciabilità completa dei servizi usati nella pipeline, tra cui la versione, gli artefatti, i commit associati e gli elementi di lavoro. Quando si definisce una risorsa, questa può essere utilizzata ovunque nella pipeline. È anche possibile automatizzare completamente il flusso di lavoro DevOps sottoscrivendo gli eventi sulle risorse.

Per altre informazioni, vedere Informazioni sulle risorse e sulla definizione dello schema YAML.

Schema

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

Variabili

Quando una risorsa attiva una pipeline, vengono impostate le variabili seguenti:

resources.triggeringAlias
resources.triggeringCategory

Questi valori sono vuoti se una risorsa non attiva un'esecuzione della pipeline. La variabile Build.Reason deve essere ResourceTrigger per questi valori da impostare.

Definire una pipelines risorsa

Se si dispone di una pipeline che produce artefatti, è possibile utilizzare gli artefatti definendo una pipelines risorsa. pipelines è una risorsa dedicata solo per Azure Pipelines. È anche possibile impostare trigger in una risorsa della pipeline per i flussi di lavoro cd.

Nella definizione pipeline della risorsa è un valore univoco che è possibile usare per fare riferimento alla risorsa della pipeline in un secondo momento. source è il nome della pipeline che produce un artefatto. Usare l'etichetta definita da pipeline per fare riferimento alla risorsa della pipeline da altre parti della pipeline, ad esempio quando si usano variabili di risorsa della pipeline o si scaricano elementi.

Per un modo alternativo per scaricare le pipeline, vedere le attività in Pipeline Artifacts.For an alternative way to download pipeline pipeline artifacts, see the tasks in Pipeline Artifacts.

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

Importante

Quando si definisce un trigger di risorsa, se la risorsa della pipeline proviene dallo stesso repository (ad esempio self) della pipeline corrente, l'attivazione segue lo stesso ramo e il commit in cui viene generato l'evento. Tuttavia, se la risorsa della pipeline proviene da un repository diverso, la pipeline corrente viene attivata nel ramo predefinito del repository self.

Valutazione della versione dell'artefatto

La versione degli artefatti della pipeline di risorse dipende dalla modalità di attivazione della pipeline.

Se la pipeline viene eseguita perché è stata attivata manualmente o a causa di un'esecuzione pianificata, la versione della versione dell'artefatto è definita dai valori delle versionproprietà , branche tags .

Proprietà specificate Versione dell'artefatto
version Artefatti della compilazione con il numero di esecuzione specificato
branch Artefatti della build più recente eseguita nel ramo specificato
tags Elenco Artefatti della build più recente con tutti i tag specificati
branch e tags elenco Artefatti della build più recente eseguita nel ramo specificato e con tutti i tag specificati
None Artefatti della build più recente in tutti i rami

Di seguito è descritto un esempio. Si supponga che la pipeline contenga la definizione di risorsa seguente.

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

Quando si attiva manualmente l'esecuzione della pipeline, la versione degli artefatti della MyCIAlias pipeline è quella della build più recente eseguita nel main ramo e con i Production tag e PrepProduction .

Quando la pipeline viene attivata perché una delle relative pipeline di risorse viene completata, la versione degli artefatti è quella della pipeline di attivazione. I valori delle versionproprietà , branche tags vengono ignorati.

Trigger specificati Risultato
branches Viene attivata una nuova esecuzione della pipeline corrente ogni volta che la pipeline di risorse completa correttamente un'esecuzione nei include rami
tags Viene attivata una nuova esecuzione della pipeline corrente ogni volta che la pipeline di risorse completa correttamente un'esecuzione contrassegnata con tutti i tag specificati
stages Viene attivata una nuova esecuzione della pipeline corrente ogni volta che la pipeline di risorse ha eseguito correttamente l'oggetto specificato stages
branches, tags e stages Viene attivata una nuova esecuzione della pipeline corrente ogni volta che l'esecuzione della pipeline di risorse soddisfa tutte le condizioni di ramo, tag e fasi
trigger: true Viene attivata una nuova esecuzione della pipeline corrente ogni volta che la pipeline di risorse completa correttamente un'esecuzione
Niente Non viene attivata alcuna nuova esecuzione della pipeline corrente quando la pipeline di risorse completa correttamente un'esecuzione

Di seguito è descritto un esempio. Si supponga che la pipeline contenga la definizione di risorsa seguente.

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

La pipeline verrà eseguita ogni volta che la SmartHotel-CI pipeline viene eseguita in uno dei releases rami o nel main ramo , viene contrassegnata con e VerifiedSignede ha completato entrambe le Production fasi e PreProduction .

download per le pipeline

Tutti gli artefatti della pipeline corrente e da tutte le pipeline risorse vengono scaricati e resi disponibili automaticamente all'inizio di ogni deployment processo. È possibile eseguire l'override di questo comportamento. Per altre informazioni, vedere Artefatti della pipeline. Gli artefatti normali di "processo" non vengono scaricati automaticamente. Usare download in modo esplicito quando necessario.

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

Gli artefatti dalla pipeline risorsa vengono scaricati nella $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> cartella.

Variabili delle risorse della pipeline

In ogni esecuzione, i metadati per una risorsa della pipeline sono disponibili per tutti i processi sotto forma di variabili predefinite. <Alias> è l'identificatore assegnato per la risorsa della pipeline. Le variabili delle risorse della pipeline sono disponibili solo in fase di esecuzione.

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

Per altre informazioni, vedere Metadati delle risorse della pipeline come variabili predefinite.

Definire una builds risorsa

Se si dispone di un sistema di compilazione CI esterno che produce artefatti, è possibile utilizzare gli artefatti con una builds risorsa. Una builds risorsa può essere qualsiasi sistema CI esterno come Jenkins, TeamCity, CircleCI e così via.

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 è una categoria estendibile. È possibile scrivere un'estensione per utilizzare gli artefatti dal servizio di compilazione e introdurre un nuovo tipo di servizio come parte di builds. Jenkins è un tipo di risorsa in builds.

Importante

I trigger sono supportati solo per Jenkins ospitati in cui Azure DevOps ha una linea di visualizzazione con il server Jenkins.

downloadBuild attività per le compilazioni

È possibile utilizzare artefatti dalla build risorsa come parte dei processi usando l'attività downloadBuild . In base al tipo di build risorsa definita, questa attività viene risolta automaticamente nell'attività di download corrispondente per il servizio durante l'esecuzione.

Gli artefatti dalla build risorsa vengono scaricati nella $(PIPELINE.WORKSPACE)/<build-identifier>/ cartella.

Importante

build gli artefatti delle risorse non vengono scaricati automaticamente nei processi o nei processi deploy-jobs. È necessario aggiungere in modo esplicito l'attività per l'utilizzo downloadBuild degli artefatti.

- 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

Definire una repositories risorsa

Se la pipeline include modelli in un altro repository o se si vuole usare il checkout multi-repository con un repository che richiede una connessione al servizio, è necessario informare il sistema su tale repository. La repository parola chiave consente di specificare un repository esterno.

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

Le pipeline supportano i valori seguenti per il tipo di repository: git, githubgithubenterprise, e bitbucket. Il git tipo fa riferimento ai repository Git di Azure Repos.

Tipo specificato Risultato Esempio
type: git Il name valore fa riferimento a un altro repository nello stesso progetto. name: otherRepo Per fare riferimento a un repository in un altro progetto all'interno della stessa organizzazione, anteporre il nome al nome del progetto. Un esempio è name: OtherProject/otherRepo.
type: github Il name valore è il nome completo del repository GitHub e include l'utente o l'organizzazione. name: Microsoft/vscode
type: githubenterprise il name valore è il nome completo del repository GitHub Enterprise e include l'utente o l'organizzazione. name: Microsoft/vscode
type: bitbucket Il name valore è il nome completo del repository Bitbucket Cloud e include l'utente o l'organizzazione. name: MyBitbucket/vscode

I repository GitHub Enterprise richiedono una connessione al servizio GitHub Enterprise per l'autorizzazione.

I repository di Bitbucket Cloud richiedono una connessione al servizio cloud Bitbucket per l'autorizzazione.

Variabili

In ogni esecuzione, i metadati per una risorsa del repository sono disponibili per tutti i processi sotto forma di variabili di runtime. <Alias> è l'identificatore assegnato per la risorsa del repository.

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

Variabili

In ogni esecuzione, i metadati per una risorsa del repository sono disponibili per tutti i processi sotto forma di variabili di runtime. <Alias> è l'identificatore assegnato per la risorsa del repository.

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

Usare checkout per usare il repository

Usare checkout la parola chiave per usare i repository definiti come parte della repository risorsa.

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.

I repository dalla repository risorsa non vengono sincronizzati automaticamente nei processi. Usare checkout per recuperare i repository come parte dei processi.

Per altre informazioni, vedere Estrazione di più repository nella pipeline.

Definire una containers risorsa

Se è necessario usare un'immagine del contenitore come parte della pipeline di integrazione continua/recapito continuo (CI/CD), è possibile ottenerla usando containers. Una risorsa contenitore può essere un registro Docker pubblico o privato o Registro Azure Container.

Se è necessario usare immagini dal registro Docker come parte della pipeline, è possibile definire una risorsa contenitore generica (non type è necessaria una parola chiave).

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

È possibile usare una risorsa contenitore generica come immagine utilizzata come parte del processo oppure può essere usata anche per i processi contenitore. Se la pipeline richiede il supporto di uno o più servizi, è necessario creare e connettersi ai contenitori del servizio. È possibile usare i volumi per condividere i dati tra i servizi.

È possibile usare un tipo di risorsa contenitore di prima classe per Registro Azure Container (ACR) per usare le immagini del Registro Azure Container. Questo tipo di risorse può essere usato come parte dei processi e anche per abilitare i trigger automatici della pipeline. Per usare i trigger automatici della pipeline, è necessario disporre delle autorizzazioni di Collaboratore o Proprietario per Registro Azure Container. Per altre informazioni, vedere Registro Azure Container ruoli e autorizzazioni.

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

Nota

La sintassi usata per abilitare i trigger del contenitore per tutti i tag di immagine (enabled: 'true') è diversa dalla sintassi usata per altri trigger di risorse. Prestare particolare attenzione all'uso della sintassi corretta per una risorsa specifica.

Nota

Le connessioni al servizio che usano la federazione dell'identità del carico di lavoro non sono supportate in azureSubscription.

Variabili di risorsa contenitore

Dopo aver definito un contenitore come risorsa, i metadati dell'immagine del contenitore vengono passati alla pipeline sotto forma di variabili. Le informazioni come immagine, registro e dettagli di connessione sono accessibili in tutti i processi da usare nelle attività di distribuzione del contenitore.

Le variabili delle risorse del contenitore funzionano con Docker e Registro Azure Container. Non è possibile usare le variabili delle risorse del contenitore per i contenitori di immagini locali.

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

La variabile location è applicabile solo per ACR il tipo di risorse del contenitore.

Definire una packages risorsa

È possibile usare pacchetti GitHub NuGet e npm come risorsa nelle pipeline YAML.

Quando si specificano package le risorse, impostare il pacchetto come NuGet o npm. È anche possibile abilitare trigger di pipeline automatizzati quando viene rilasciata una nuova versione del pacchetto.

Per usare i pacchetti GitHub, usare l'autenticazione basata su token di accesso personale e creare una connessione al servizio GitHub che usa i token di accesso personale.

Per impostazione predefinita, i pacchetti non vengono scaricati automaticamente nei processi. Per scaricare, usare 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

Definire una webhooks risorsa

Nota

I webhook sono stati rilasciati in Azure DevOps Server 2020.1.

Con altre risorse (ad esempio, pipeline, contenitori, compilazione e pacchetti), è possibile usare gli artefatti e abilitare trigger automatizzati. Tuttavia, non è possibile automatizzare il processo di distribuzione in base ad altri eventi o servizi esterni. La webhooks risorsa consente di integrare la pipeline con qualsiasi servizio esterno e automatizzare il flusso di lavoro. È possibile sottoscrivere qualsiasi evento esterno tramite i webhook (GitHub, GitHub Enterprise, Nexus, Artifactory e così via) e attivare le pipeline.

Per configurare i trigger webhook, seguire questa procedura.

  1. Configurare un webhook nel servizio esterno. Quando si crea il webhook, è necessario fornire le informazioni seguenti:

    • URL richiesta

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

    • Segreto - Facoltativo. Se è necessario proteggere il payload JSON, specificare il valore Secret .

  2. Creare una nuova connessione al servizio "Webhook in ingresso". Questa connessione è un tipo di connessione ai servizi appena introdotto che consente di definire le seguenti informazioni importanti:

    • Nome webhook: il nome del webhook deve corrispondere al webhook creato nel servizio esterno.
    • Intestazione HTTP: nome dell'intestazione HTTP nella richiesta contenente il valore hash HMAC-SHA1 del payload per la verifica della richiesta. Ad esempio, per GitHub, l'intestazione della richiesta è "X-Hub-Signature".
    • Segreto : il segreto viene usato per verificare l'hash HMAC-SHA1 del payload usato per la verifica della richiesta in ingresso (facoltativo). Se è stato usato un segreto durante la creazione del webhook, è necessario specificare la stessa chiave privata.

    Incoming Webhook Service connection

  3. Un nuovo tipo di risorsa chiamato webhooks viene introdotto nelle pipeline YAML. Per sottoscrivere un evento webhook, definire una risorsa webhook nella pipeline e puntare alla connessione al servizio webhook in ingresso. È anche possibile definire altri filtri sulla risorsa webhook, in base ai dati del payload JSON, per personalizzare i trigger per ogni pipeline. Utilizzare i dati del payload sotto forma di variabili nei processi.

  4. Ogni volta che la connessione al servizio Webhook in ingresso riceve un evento webhook, viene attivata una nuova esecuzione per tutte le pipeline sottoscritte all'evento webhook. È possibile usare i dati del payload JSON nei processi usando il formato ${{ 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

I webhook automatizzano il flusso di lavoro in base a qualsiasi evento webhook esterno non supportato dalle risorse di prima classe, ad esempio pipeline, compilazioni, contenitori e pacchetti. Inoltre, per i servizi locali in cui Azure DevOps non ha visibilità sul processo, è possibile configurare webhook nel servizio e attivare automaticamente le pipeline.

Selezione della versione manuale per le risorse nella finestra di dialogo Crea esecuzione

Quando si attiva manualmente una pipeline YAML cd, viene valutata automaticamente la versione predefinita per le risorse definite nella pipeline, in base agli input forniti. Tuttavia, è possibile scegliere di selezionare una versione diversa dalla selezione della versione della risorsa quando si crea un'esecuzione.

  1. Nel riquadro Crea esecuzione selezionare Risorse. In questa pipeline viene visualizzato un elenco di risorse utilizzate.

  2. Selezionare una risorsa e selezionare una versione specifica dall'elenco delle versioni disponibili. La selezione delle versioni delle risorse è supportata per le risorse della pipeline, della compilazione, del repository, del contenitore e del pacchetto.

    Pipeline Version Picker

Per le risorse della pipeline, è possibile visualizzare tutte le esecuzioni disponibili in tutti i rami. Cercarli in base al numero o al ramo della pipeline. Selezionare un'esecuzione riuscita, non riuscita o in corso. Questa flessibilità garantisce che sia possibile eseguire la pipeline cd se si è certi che abbia prodotto tutti gli artefatti necessari. Non è necessario attendere il completamento o la ripetizione dell'esecuzione dell'integrazione continua a causa di un errore di fase non correlato nell'esecuzione dell'integrazione continua. Tuttavia, quando si valuta la versione predefinita per i trigger pianificati viene valutata correttamente l'esecuzione dell'integrazione continua completata o se non si usa la selezione della versione manuale.

Per le risorse in cui non è possibile recuperare le versioni disponibili, ad esempio i pacchetti GitHub, viene visualizzata una casella di testo come parte della selezione della versione, in modo da poter fornire la versione per l'esecuzione da selezionare.

Autorizzare una pipeline YAML

Le risorse devono essere autorizzate prima di poterle usare. Un proprietario della risorsa controlla gli utenti e le pipeline che possono accedere a tale risorsa. La pipeline deve essere autorizzata a usare la risorsa. Vedere i modi seguenti per autorizzare una pipeline YAML.

  • Passare all'esperienza di amministrazione della risorsa. Ad esempio, i gruppi di variabili e i file sicuri vengono gestiti nella pagina Libreria in Pipeline. I pool di agenti e le connessioni al servizio vengono gestiti nelle impostazioni di Project. Qui è possibile autorizzare tutte le pipeline ad accedere a tale risorsa. Questa autorizzazione è utile se non è necessario limitare l'accesso a una risorsa, ad esempio testare le risorse.

  • Quando si crea una pipeline per la prima volta, tutte le risorse a cui viene fatto riferimento nel file YAML vengono autorizzate automaticamente per l'uso dalla pipeline, se si è membri del ruolo Utente per tale risorsa. Quindi, le risorse a cui si fa riferimento nel file YAML quando si crea una pipeline vengono autorizzate automaticamente.

  • Quando si apportano modifiche al file YAML e si aggiungono risorse, la compilazione ha esito negativo con un errore simile all'errore seguente: Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.

    In questo caso viene visualizzata un'opzione per autorizzare le risorse nella compilazione non riuscita. Se si è membri del ruolo Utente per la risorsa, è possibile selezionare questa opzione. Dopo aver autorizzato le risorse, è possibile avviare una nuova compilazione.

  • Verificare che i ruoli di sicurezza del pool di agenti per il progetto siano corretti.

Impostare i controlli di approvazione per le risorse

È possibile controllare manualmente quando una risorsa viene eseguita con controlli e modelli di approvazione. Con il controllo di approvazione del modello necessario, è possibile richiedere qualsiasi pipeline usando una risorsa o un ambiente estende anche da un modello YAML specifico. L'impostazione di un'approvazione del modello richiesta migliora la sicurezza. Assicurarsi che la risorsa venga usata solo in condizioni specifiche con un modello. Altre informazioni su come migliorare la sicurezza della pipeline con modelli e risorse.

Tracciabilità

Microsoft offre la tracciabilità completa per qualsiasi risorsa utilizzata a livello di processo di pipeline o distribuzione.

Tracciabilità delle pipeline

Per ogni esecuzione della pipeline vengono visualizzate le informazioni seguenti.

  • Risorsa che ha attivato la pipeline, se attivata da una risorsa.

    Resource trigger in a pipeline

  • Versione della risorsa e degli artefatti utilizzati.

    Consumed artifacts in pipeline run

  • Commit associati a ogni risorsa.

    Commits in pipeline run

  • Elementi di lavoro associati a ogni risorsa.

Tracciabilità dell'ambiente

Ogni volta che una pipeline viene distribuita in un ambiente, è possibile visualizzare un elenco di risorse utilizzate. La visualizzazione seguente include le risorse utilizzate come parte dei processi di distribuzione e i commit e gli elementi di lavoro associati.

Commits in environment

Visualizzare le informazioni sulle pipeline CD associate nelle pipeline CI

Per fornire la tracciabilità end-to-end, è possibile tenere traccia delle pipeline cd che utilizzano una pipeline CI. È possibile visualizzare l'elenco delle pipeline YAML cd in cui viene utilizzata un'esecuzione della pipeline CI tramite la pipeline risorsa. Se altre pipeline usano la pipeline CI, viene visualizzata una scheda "Pipeline associate" nella visualizzazione di esecuzione. Qui è possibile trovare tutte le esecuzioni della pipeline che usano la pipeline e gli artefatti.

CD pipelines information in CI pipeline

Problemi di attivazione delle risorse YAML: supporto e tracciabilità

Può generare confusione quando l'esecuzione dei trigger della pipeline non riesce. È stata aggiunta una nuova voce di menu nella pagina di definizione della pipeline denominata Problemi di trigger, in cui è possibile scoprire perché i trigger non sono in esecuzione. Per accedere a questa pagina, aprire la cronologia della pipeline. I problemi di trigger sono disponibili solo per le risorse non del repository.

Select Trigger Issues from the navigation.

I trigger di risorsa possono non essere eseguiti per i motivi seguenti.

  • Se l'origine della connessione al servizio fornita non è valida o se sono presenti errori di sintassi nel trigger, il trigger non è configurato, generando un errore.

  • Se le condizioni del trigger non corrispondono, il trigger non verrà eseguito. Viene visualizzato un avviso in modo da comprendere il motivo per cui le condizioni non sono state soddisfatte.

    Trigger issues supportability

Passaggi successivi

Aggiungere e usare gruppi di variabili

Domande frequenti

Perché è consigliabile usare pipeline resources anziché il download collegamento?

L'uso di una pipelines risorsa è un modo per utilizzare gli artefatti da una pipeline di integrazione continua e configurare anche i trigger automatizzati. Una risorsa offre visibilità completa sul processo visualizzando la versione utilizzata, gli artefatti, i commit e gli elementi di lavoro. Quando si definisce una risorsa pipeline, gli artefatti associati vengono scaricati automaticamente nei processi di distribuzione.

È possibile scegliere di scaricare gli artefatti nei processi di compilazione o di eseguire l'override del comportamento di download nei processi di distribuzione con download. Per altre informazioni, vedere steps.download.

Perché è consigliabile usare resources anziché l'attività Scarica artefatti della pipeline?

Quando si usa direttamente l'attività Scarica artefatti della pipeline, si perde la tracciabilità e i trigger. A volte è opportuno usare direttamente l'attività Scarica artefatti pipeline. Ad esempio, potrebbe essere presente un'attività script archiviata in un modello diverso e l'attività script richiede il download degli artefatti di una compilazione. In alternativa, è possibile che non si sappia se un utente che usa un modello vuole aggiungere una risorsa della pipeline. Per evitare dipendenze, è possibile usare l'attività Scarica artefatti pipeline per passare tutte le informazioni di compilazione a un'attività.

Come è possibile attivare un'esecuzione della pipeline quando l'immagine dell'hub Docker viene aggiornata?

È necessario configurare una pipeline di versione classica perché il trigger di risorse dei contenitori non è disponibile per l'hub Docker per le pipeline YAML.

  1. Creare una nuova connessione al servizio Docker Hub.

  2. Creare una pipeline di versione classica e aggiungere un artefatto dell'hub Docker. Impostare la connessione al servizio. Selezionare lo spazio dei nomi, il repository, la versione e l'alias di origine.

    Add a Docker Hub artifact.

  3. Selezionare il trigger e attivare o disattivare il trigger di distribuzione continua su Abilita. Si creerà una versione ogni volta che si verifica un push Docker nel repository selezionato.

  4. Creare una nuova fase e un nuovo processo. Aggiungere due attività, l'account di accesso Docker e Bash:

  • L'attività Docker include l'azione e registra l'utente login nell'hub Docker.

  • L'attività Bash esegue docker pull <hub-user>/<repo-name>[:<tag>]. Sostituire hub-user, repo-namee tag con i valori.

    Add Docker login and Bash tasks.

Come è possibile convalidare e risolvere i problemi dei webhook?

  1. Creare una connessione al servizio.

  2. Fare riferimento alla connessione al servizio e denominare il webhook nella webhooks sezione .

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. Esegui la pipeline. Quando si esegue la pipeline, il webhook verrà creato in Azure come attività distribuita per l'organizzazione.

  4. Eseguire una POST chiamata API con json valido nel corpo a https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Se si riceve una risposta di codice di stato 200, il webhook è pronto per l'utilizzo dalla pipeline. Se si riceve una risposta di codice di stato 500 con l'errore Cannot find webhook for the given webHookId ..., il codice potrebbe trovarsi in un ramo che non è il ramo predefinito.

    1. Aprire la pipeline.
    2. Seleziona Modifica.
    3. Selezionare il menu Select more actions menu altre azioni .
    4. Selezionare Trigger YAML Get Sources (Recupera>origini YAML).>
    5. Passare a Ramo predefinito per le compilazioni manuali e pianificate per aggiornare il ramo di funzionalità.
    6. Selezionare Salva e coda.
    7. Dopo l'esecuzione di questa pipeline, eseguire una POST chiamata API con json valido nel corpo a https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Si dovrebbe ora ricevere una risposta al codice di stato 200.