Definire le risorse in YAML

Azure DevOps Services

Le risorse in YAML rappresentano origini di pipeline, compilazioni, repository, contenitori, pacchetti e webhook. Le risorse forniscono 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, può essere utilizzata ovunque nella pipeline. È inoltre possibile automatizzare completamente il flusso di lavoro DevOps sottoscriendo per attivare eventi sulle risorse.

Per altre informazioni, vedere Informazioni sulle risorse

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 usare 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.

Per un modo alternativo per scaricare le pipeline, vedere le attività 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 risorse, se la risorsa della pipeline proviene dallo stesso repository (ad esempio self) della pipeline corrente, attivando 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 della pipeline, l'esecuzione della compilazione CI, che viene selezionata nell'esecuzione della pipeline, viene controllata dal modo in cui viene attivata l'esecuzione della pipeline.

Se si crea l'esecuzione della pipeline viene creata manualmente o da un trigger pianificato, la versione predefinita, il ramo e i tag vengono usati per valutare la versione della pipeline CI.

Informazioni fornite Risultato
Versione di compilazione # Tale versione viene eseguita.
Ramo La versione più recente del ramo specificato viene eseguita.
Elenco tag L'esecuzione più recente con tutti i tag corrispondenti viene eseguita.
Elenco rami e tag L'esecuzione più recente dal ramo fornito e che include le esecuzioni dei tag corrispondenti.
Nothing La versione più recente in tutti i rami viene eseguita.
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

Se la pipeline viene attivata automaticamente, la versione della pipeline CI viene selezionata in base all'evento trigger. Le informazioni sulla versione predefinite fornite sono irrilevanti.

Informazioni fornite Risultato
Rami Una nuova pipeline viene attivata ogni volta che un'esecuzione CI viene completata correttamente che corrisponde ai rami inclusi.
Tag Una nuova pipeline viene attivata ogni volta che un'esecuzione CI viene completata correttamente che corrisponde a tutti i tag menzionati.
Fasi Una nuova pipeline viene attivata ogni volta che un'esecuzione CI include tutte le fasi indicate vengono completate correttamente.
Rami, tag e fasi Una nuova esecuzione della pipeline viene attivata ogni volta che un'esecuzione CI corrisponde a tutte le condizioni.
Solo trigger: true Una nuova esecuzione della pipeline viene attivata ogni volta che un'esecuzione CI viene completata correttamente.
Nothing Nessuna esecuzione della pipeline viene attivata. I trigger vengono disabilitati per impostazione predefinita, a meno che non vengano abilitati in modo specifico.
resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction
      

download per le pipeline

Tutti gli artefatti dalla pipeline corrente e da tutte le pipeline risorse vengono scaricati automaticamente e resi disponibili all'inizio di ogni deployment processo. È possibile eseguire l'override di questo comportamento. Per altre informazioni, vedere Pipeline Artifacts. Gli artefatti "job" regolari 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

Artifacts dalla pipeline risorsa scaricata nella $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> cartella.

Variabili di risorsa della pipeline

In ogni esecuzione i metadati per una risorsa della pipeline sono disponibili per tutti i processi sotto forma di variabili predefinite. L'identificatore <Alias> 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

Definire una builds risorsa

Se si dispone di un sistema di compilazione CI esterno che produce artefatti, è possibile usare gli artefatti con una builds risorsa. Una builds risorsa può essere qualsiasi sistema CI esterno, ad esempio 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 elementi 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 ospitato in cui Azure DevOps ha una linea di vista con il server Jenkins.

downloadBuild attività per le compilazioni

È possibile usare gli artefatti dalla risorsa come parte dei processi usando l'attività builddownloadBuild . In base al tipo di build risorsa definita, questa attività risolve automaticamente l'attività di download corrispondente per il servizio durante l'esecuzione.

Artifacts dalla build risorsa scaricata nella $(PIPELINE.WORKSPACE)/<build-identifier>/ cartella.

Importante

build gli artefatti delle risorse non vengono scaricati automaticamente nei processi o nei processi di distribuzione. È 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  # identifier (A-Z, a-z, 0-9, and underscore)
    type: enum  # see the following "Type" topic
    name: string  # repository name (format depends on `type`)
    ref: string  # ref name to use; defaults to 'refs/heads/main'
    endpoint: string  # name of the service connection to use (for types that aren't Azure Repos)
    trigger:  # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos)
      branches:
        include: [ string ] # branch names which trigger a build
        exclude: [ string ] # branch names which won't
      tags:
        include: [ string ] # tag names which trigger a build
        exclude: [ string ] # tag names which won't
      paths:
        include: [ string ] # file paths which must match to trigger a build
        exclude: [ string ] # file paths which won't trigger a build

Tipo

Pipelines supportano i valori seguenti per il tipo di repository: git, github, githubenterprisee bitbucket. Il git tipo fa riferimento a Azure Repos repository Git.

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

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

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

Usare checkout per utilizzare il repository

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

SCHEMA

steps:
- checkout: string  # identifier for your repository resource
  clean: boolean  # if true, execute `execute git clean -ffdx && git reset --hard HEAD` before fetching
  fetchDepth: number  # the depth of commits to ask Git to fetch; defaults to no limit
  lfs: boolean  # whether to download Git-LFS files; defaults to false
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules; defaults to not checking out submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1); defaults to a directory called `s`
  persistCredentials: boolean  # if 'true', leave the OAuth token in the Git config after the initial fetch; defaults to false

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

Per altre informazioni, vedere Controllare 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 utilizzare 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.

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.

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.

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 NuGet e npm GitHub 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 (PAT) 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

Con altre risorse, ad esempio pipeline, contenitori, compilazione e pacchetti, è possibile utilizzare 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 al servizio appena introdotto che consente di definire le informazioni importanti seguenti:

    • Nome webhook: il nome del webhook deve corrispondere al webhook creato nel servizio esterno.
    • Intestazione HTTP : nome dell'intestazione HTTP nella richiesta che contiene 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. Viene introdotto un nuovo tipo di risorsa chiamato webhooks 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. Risorse come 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 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 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 nell'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 dell'esecuzione dell'integrazione continua o la riesecuzione 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'integrazione continua completata o se non si usa selezione 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 da selezionare per l'esecuzione.

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 Pipelines. 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 viene fatto 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 necessaria 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 fornisce la tracciabilità completa per qualsiasi risorsa utilizzata a livello di processo di pipeline o distribuzione.

Tracciabilità della 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 esecuzioni di 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 supportano 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

Domande frequenti

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

L'uso di una pipelines risorsa è un modo per utilizzare gli artefatti da una pipeline ci e configurare anche 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 della 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. L'attività download usa internamente l'attività Scarica pipeline Artifacts.

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

Quando si usa direttamente l'attività Scarica pipeline Artifacts, si perde la tracciabilità e i trigger. A volte è opportuno usare direttamente l'attività Scarica pipeline Artifacts. 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, potrebbe non essere possibile sapere se un utente che usa un modello vuole aggiungere una risorsa della pipeline. Per evitare dipendenze, è possibile usare l'attività Scarica pipeline Artifacts per passare tutte le informazioni di compilazione a un'attività.

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

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

  1. Creare una nuova connessione al servizio Docker Hub.

  2. Creare una pipeline di versione classica e aggiungere un elemento Docker Hub. 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 login e consente di accedere Docker Hub.

  • 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.