Configurare le pianificazioni per le pipeline

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

Azure Pipelines offre diversi tipi di trigger per configurare l'avvio della pipeline.

• I trigger pianificati avviano la pipeline in base a una pianificazione, ad esempio una compilazione notturna. Questo articolo fornisce indicazioni sull'uso di trigger pianificati per eseguire le pipeline in base a una pianificazione.
• I trigger basati su eventi avviano la pipeline in risposta a eventi, ad esempio la creazione di una richiesta pull o il push in un ramo. Per informazioni sull'uso di trigger basati su eventi, vedere Trigger in Azure Pipelines.

È possibile combinare trigger pianificati e basati su eventi nelle pipeline, ad esempio per convalidare la compilazione ogni volta che viene effettuato un push (trigger CI), quando viene effettuata una richiesta pull (trigger pr) e una compilazione notturna (trigger pianificato). Se si vuole compilare la pipeline solo in base a una pianificazione e non in risposta ai trigger basati su eventi, assicurarsi che la pipeline non abbia altri trigger abilitati. Ad esempio, le pipeline YAML in un repository GitHub hanno trigger CI e trigger di richiesta pull abilitati per impostazione predefinita. Per informazioni sulla disabilitazione dei trigger predefiniti, vedere Trigger in Azure Pipelines e passare alla sezione relativa al tipo di repository.

Trigger pianificati

YAML

Importante

I trigger pianificati definiti usando l'interfaccia utente delle impostazioni della pipeline hanno la precedenza sui trigger pianificati YAML.

Se la pipeline YAML include trigger pianificati YAML e trigger pianificati definiti dall'interfaccia utente, vengono eseguiti solo i trigger pianificati definiti dall'interfaccia utente. Per eseguire i trigger pianificati YAML definiti nella pipeline YAML, è necessario rimuovere i trigger pianificati definiti nell'interfaccia utente delle impostazioni della pipeline. Dopo aver rimosso tutti i trigger pianificati dell'interfaccia utente, è necessario eseguire un push affinché i trigger pianificati YAML inizino a essere valutati.

Per eliminare i trigger pianificati dell'interfaccia utente da una pipeline YAML, vedere Impostazioni dell'interfaccia utente che sostituiscono i trigger pianificati YAML.

I trigger pianificati configurano una pipeline per l'esecuzione in base a una pianificazione definita usando la sintassi cron.

schedules:
- cron: string # cron syntax defining a schedule
  displayName: string # friendly name given to a specific schedule
  branches:
    include: [ string ] # which branches the schedule applies to
    exclude: [ string ] # which branches to exclude from the schedule
  always: boolean # whether to always run the pipeline or only if there have been source code changes since the last successful scheduled run. The default is false.
  batch: boolean # Whether to run the pipeline if the previously scheduled run is in-progress; the default is false.
  # batch is available in Azure DevOps Server 2022.1 and higher

Le pipeline pianificate in YAML hanno i vincoli seguenti.

• Il fuso orario per le pianificazioni cron è UTC.
• Se si specifica una exclude clausola senza una include clausola per branches, equivale a specificare * nella include clausola .
• Non è possibile usare le variabili della pipeline quando si specificano le pianificazioni.
• Se si usano modelli nel file YAML, le pianificazioni devono essere specificate nel file YAML principale e non nei file modello.

Considerazioni sul ramo per i trigger pianificati

I trigger pianificati vengono valutati per un ramo quando si verificano gli eventi seguenti.

• Viene creata una pipeline.
• Il file YAML di una pipeline viene aggiornato, da un push o modificandolo nell'editor della pipeline.
• Il percorso del file YAML di una pipeline viene aggiornato per fare riferimento a un file YAML diverso. Questa modifica aggiorna solo il ramo predefinito e quindi seleziona solo le pianificazioni nel file YAML aggiornato per il ramo predefinito. Se altri rami uniscono successivamente il ramo predefinito, ad esempio git pull origin main, i trigger pianificati dal file YAML appena a cui si fa riferimento vengono valutati per tale ramo.
• Viene creato un nuovo ramo.

Dopo che uno di questi eventi si verifica in un ramo, vengono aggiunte tutte le esecuzioni pianificate per tale ramo, se tale ramo corrisponde ai filtri di ramo per i trigger pianificati contenuti nel file YAML in tale ramo.

Importante

Le esecuzioni pianificate per un ramo vengono aggiunte solo se il ramo corrisponde ai filtri di ramo per i trigger pianificati nel file YAML in tale ramo specifico.

Ad esempio, viene creata una pipeline con la pianificazione seguente e questa versione del file YAML viene archiviata nel main ramo . Questa pianificazione compila il main ramo su base giornaliera.

# YAML file in the main branch
schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main

Viene quindi creato un nuovo ramo basato su main, denominato new-feature. I trigger pianificati dal file YAML nel nuovo ramo vengono letti e, poiché non esiste alcuna corrispondenza per il new-feature ramo, non vengono apportate modifiche alle compilazioni pianificate e il new-feature ramo non viene compilato usando un trigger pianificato.

Se new-feature viene aggiunto all'elenco branches e questa modifica viene inserita nel new-feature ramo , il file YAML viene letto e, poiché new-feature è ora presente nell'elenco dei rami, viene aggiunta una compilazione pianificata per il new-feature ramo.

# YAML file in the new-feature-branch
schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main
    - new-feature

Si consideri ora che un ramo denominato release viene creato in mainbase a e quindi release viene aggiunto ai filtri di ramo nel file YAML nel main ramo , ma non nel ramo appena creato release .

# YAML file in the release branch
schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main

# YAML file in the main branch with release added to the branches list
schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main
    - release

Poiché release è stato aggiunto ai filtri del ramo nel main ramo, ma non ai filtri dei rami nel release ramo, il release ramo non verrà compilato in base a tale pianificazione. Solo quando il release ramo viene aggiunto ai filtri di ramo nel file YAML nel ramo di rilascio, la compilazione pianificata verrà aggiunta all'utilità di pianificazione.

Considerazioni batch per i trigger pianificati

La batch proprietà configura se eseguire la pipeline se l'esecuzione pianificata in precedenza è in corso; l'impostazione predefinita è false. Questo avviene indipendentemente dalla versione del repository della pipeline.

Nella tabella seguente viene descritto come always e batch interagire.

Sempre	Batch	Comportamento
false	false	La pipeline viene eseguita solo se è presente una modifica rispetto all'ultima esecuzione pianificata della pipeline.
false	true	La pipeline viene eseguita solo se è presente una modifica rispetto all'ultima esecuzione pianificata della pipeline pianificata e non è prevista alcuna esecuzione della pipeline in corso.
true	false	La pipeline viene eseguita in base alla pianificazione cron.
true	true	La pipeline viene eseguita in base alla pianificazione cron.

Importante

Quando always è true, la pipeline viene eseguita in base alla pianificazione cron, anche quando batch è true.

Variabile Build.CronSchedule.DisplayName

Quando una pipeline è in esecuzione a causa di un trigger pianificato cron, la variabile predefinita Build.CronSchedule.DisplayName contiene la displayName della pianificazione cron che ha attivato l'esecuzione della pipeline.

La pipeline YAML può contenere più pianificazioni cron ed è possibile che la pipeline esegua fasi o processi diversi in base alla pianificazione cron eseguita. Ad esempio, si dispone di una compilazione notturna e di una compilazione settimanale e si vuole eseguire una determinata fase solo durante la compilazione notturna. È possibile usare la Build.CronSchedule.DisplayName variabile in una condizione di processo o fase per determinare se eseguire tale processo o fase.

- stage: stage1
  # Run this stage only when the pipeline is triggered by the 
  # "Daily midnight build" cron schedule
  condition: eq(variables['Build.CronSchedule.DisplayName'], 'Daily midnight build')

Per altri esempi, vedere gli esempi schedules.cron.

Classico

Selezionare i giorni e gli orari in cui si vuole eseguire la compilazione usando l'editor classico.

Se il repository è Git, GitHub o Altro git di Azure, è anche possibile specificare rami da includere ed escludere. Se si desidera utilizzare caratteri jolly, digitare la specifica del ramo ( ad esempio features/modules/*, ) e quindi premere INVIO.

Esempi

YAML

L'esempio seguente definisce due pianificazioni:

schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/ancient/*
- cron: '0 12 * * 0'
  displayName: Weekly Sunday build
  branches:
    include:
    - releases/*
  always: true

La prima pianificazione, compilazione di mezzanotte giornaliera, esegue una pipeline a mezzanotte ogni giorno, ma solo se il codice è stato modificato dopo l'ultima esecuzione pianificata, per main e tutti i releases/* rami, ad eccezione dei rami in releases/ancient/*.

La seconda pianificazione, la compilazione Settimanale domenicale, esegue una pipeline a mezzogiorno di domenica, indipendentemente dal fatto che il codice sia stato modificato o meno dall'ultima esecuzione, per tutti i releases/* rami.

Nota

Il fuso orario per le pianificazioni cron è UTC, quindi in questi esempi la compilazione di mezzanotte e la build di mezzogiorno sono a mezzanotte e mezzogiorno in formato UTC.

Per altri esempi, vedere Migrazione dall'editor classico.

Classico

Esempio: Compilazione notturna del repository Git in più fusi orari

In questo esempio, il trigger pianificato dell'editor classico ha due voci, che producono le compilazioni seguenti.

• Ogni lunedì - venerdì alle 3:00 (UTC + 5:30 fuso orario), i rami di compilazione che soddisfano i criteri di features/india/* filtro dei rami

  

• Ogni lunedì - venerdì alle 3:00 (UTC - 5:00 fuso orario), i rami di compilazione che soddisfano i criteri di features/nc/* filtro dei rami

  

Esempio: Compilazione notturna con frequenze diverse

Azure Pipelines e il server Azure DevOps 2019

In questo esempio, il trigger pianificato dell'editor classico ha due voci, producendo le compilazioni seguenti.

• Ogni lunedì - venerdì alle 3:00 UTC, i rami di compilazione che soddisfano i criteri di main filtro dei rami e releases/*

  

• Ogni domenica alle 3:00 UTC compilare il releases/lastversion ramo, anche se l'origine o la pipeline non è stata modificata

  

Sintassi Cron

YAML

Ogni espressione cron del trigger pianificata di Azure Pipelines è un'espressione delimitata da spazi con cinque voci nell'ordine seguente. L'espressione è racchiusa tra virgolette 'singole.

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

Campo	Valori accettati
Minuti	da 0 a 59
Ore	da 0 a 23
Giorni	Da 1 a 31
Mesi	da 1 a 12, nomi completi in inglese, prime tre lettere di nomi inglesi
Giorni della settimana	da 0 a 6 (a partire dalla domenica), nomi completi dell'inglese, prime tre lettere di nomi inglesi

I valori possono essere nei formati seguenti.

Formattazione	Esempio	Descrizione
Wildcard (Carattere jolly)	*	Corrisponde a tutti i valori per questo campo
Valore singolo	5	Specifica un singolo valore per questo campo
Delimitato da virgole	3,5,6	Specifica più valori per questo campo. È possibile combinare più formati, ad esempio 1,3-6
Intervalli	1-3	Intervallo inclusivo di valori per questo campo
Intervalli	*/4 oppure 1-5/2	Intervalli di corrispondenza per questo campo, ad esempio ogni quarto valore o intervallo da 1 a 5 con un intervallo di passaggio pari a 2

Esempio	Espressione Cron
Compilare ogni lunedì, mercoledì e venerdì alle 18:00	0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5 o 0 18 * * 1-5/2
Compilare ogni 6 ore	0 0,6,12,18 * * *, 0 */6 * * * o 0 0-18/6 * * *
Compilare ogni 6 ore a partire dalle 9:00	0 9,15,21 * * * oppure 0 9-21/6 * * *

Per altre informazioni sui formati supportati, vedere Espressione Crontab.

Classico

Le pianificazioni classiche vengono definite usando un editor grafico anziché una sintassi cron. Per informazioni sulla definizione di pianificazioni classiche, vedere Esempi.

Visualizzazione esecuzioni pianificate

YAML

È possibile visualizzare un'anteprima delle prossime build pianificate scegliendo Esecuzioni pianificate dal menu di scelta rapida nella pagina dei dettagli della pipeline per la pipeline.

Importante

La visualizzazione esecuzioni pianificate mostra solo le pipeline pianificate per l'esecuzione entro sette giorni dalla data corrente. Se la pianificazione cron ha un intervallo superiore a 7 giorni e l'esecuzione successiva è pianificata per l'avvio dopo sette giorni dalla data corrente, non verrà visualizzata nella visualizzazione esecuzioni pianificate.

Dopo aver creato o aggiornato i trigger pianificati, è possibile verificarli usando questa visualizzazione.

In questo esempio vengono visualizzate le esecuzioni pianificate per la pianificazione seguente.

schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main

Le finestre Esecuzioni pianificate visualizzano gli orari convertiti nel fuso orario locale impostato nel computer usato per passare al portale di Azure DevOps. In questo esempio viene visualizzato uno screenshot acquisito nel fuso orario EST.

Classico

È possibile visualizzare un'anteprima delle prossime build pianificate scegliendo Esecuzioni pianificate dal menu di scelta rapida nella pagina dei dettagli della pipeline per la pipeline.

Dopo aver creato o aggiornato i trigger pianificati, è possibile verificarli usando questa visualizzazione.

Esecuzione anche quando non sono presenti modifiche al codice

Per impostazione predefinita, la pipeline non viene eseguita come pianificata se non sono state apportate modifiche al codice dall'ultima esecuzione pianificata. Si consideri, ad esempio, che sia stata pianificata l'esecuzione di una pipeline ogni notte alle 19:00. Durante i giorni feriali, è possibile eseguire il push di varie modifiche al codice. La pipeline viene eseguita in base alla pianificazione. Durante i fine settimana non si apportano modifiche al codice. Se non sono state apportate modifiche al codice dall'esecuzione pianificata il venerdì, la pipeline non viene eseguita come pianificato durante il fine settimana.

YAML

Per forzare l'esecuzione di una pipeline anche quando non sono presenti modifiche al codice, è possibile usare la always parola chiave .

schedules:
- cron: ...
  ...
  always: true

Classico

Per configurare la pipeline pianificata per la compilazione solo se è stata apportata una modifica dall'ultima compilazione, selezionare Pianifica solo le compilazioni se l'origine o la pipeline è stata modificata.

Limiti al numero di esecuzioni pianificate nelle pipeline YAML

Esistono alcuni limiti per la frequenza con cui è possibile pianificare l'esecuzione di una pipeline. Questi limiti sono stati introdotti per evitare l'uso improprio delle risorse di Azure Pipelines, in particolare degli agenti ospitati da Microsoft. I limiti sono i seguenti:

• circa 1000 esecuzioni per pipeline alla settimana
• 10 esecuzioni per pipeline ogni 15 minuti

Migrazione dall'editor classico

Gli esempi seguenti illustrano come eseguire la migrazione delle pianificazioni dall'editor classico a YAML.

• Esempio: Compilazione notturna del repository Git in più fusi orari
• Esempio: Compilazione notturna con frequenze diverse

Esempio: Compilazione notturna del repository Git in più fusi orari

In questo esempio, il trigger pianificato dell'editor classico ha due voci, producendo le compilazioni seguenti.

• Ogni lunedì - venerdì alle 3:00 (UTC + 5:30 fuso orario), i rami di compilazione che soddisfano i criteri di features/india/* filtro dei rami

  

• Ogni lunedì - venerdì alle 3:00 (UTC - 5:00 fuso orario), i rami di compilazione che soddisfano i criteri di features/nc/* filtro dei rami

  

Il trigger pianificato YAML equivalente è:

schedules:
- cron: '30 21 * * Sun-Thu'
  displayName: M-F 3:00 AM (UTC + 5:30) India daily build
  branches:
    include:
    - /features/india/*
- cron: '0 8 * * Mon-Fri'
  displayName: M-F 3:00 AM (UTC - 5) NC daily build
  branches:
    include:
    - /features/nc/*

Nella prima pianificazione, M-F 3:00 AM (UTC + 5:30) Build giornaliera india, la sintassi cron (mm HH DD MM DW) è 30 21 * * Sun-Thu.

• Minuti e ore : 30 21 corrisponde a 21:30 UTC (9:30 PM UTC). Poiché il fuso orario specificato nell'editor classico è UTC + 5:30, è necessario sottrarre 5 ore e 30 minuti dall'ora di compilazione desiderata delle 3:00 per arrivare all'ora UTC desiderata per specificare per il trigger YAML.
• I giorni e i mesi vengono specificati come caratteri jolly perché questa pianificazione non specifica l'esecuzione solo in determinati giorni del mese o in un mese specifico.
• Giorni della settimana: Sun-Thu a causa della conversione del fuso orario, per l'esecuzione delle build alle 3:00 utc + 5:30 fuso orario India, è necessario specificare l'avvio del giorno precedente nell'ora UTC. È anche possibile specificare i giorni della settimana come 0-4 o 0,1,2,3,4.

Nella seconda pianificazione, M-F 3:00 (UTC - 5) compilazione giornaliera nc, la sintassi cron è 0 8 * * Mon-Fri.

• Minuti e ore: 0 8 viene eseguito il mapping a 8:00 AM UTC. Poiché il fuso orario specificato nell'editor classico è UTC - 5:00, è necessario aggiungere 5 ore dall'ora di compilazione desiderata delle 3:00 per arrivare all'ora UTC desiderata per specificare per il trigger YAML.
• I giorni e i mesi vengono specificati come caratteri jolly perché questa pianificazione non specifica l'esecuzione solo in determinati giorni del mese o in un mese specifico.
• Giorni della settimana : Mon-Fri poiché le conversioni del fuso orario non si estendono su più giorni della settimana per la pianificazione desiderata, non è necessario eseguire alcuna conversione qui. È anche possibile specificare i giorni della settimana come 1-5 o 1,2,3,4,5.

Importante

I fusi orari UTC nei trigger pianificati YAML non fanno riferimento all'ora legale.

Suggerimento

Quando si usano 3 giorni della settimana e si desidera un intervallo di più giorni fino al sole, sun deve essere considerato il primo giorno della settimana, ad esempio per una pianificazione di mezzanotte EST, da giovedì a domenica, la sintassi cron è 0 5 * * Sun,Thu-Sat.

Esempio: Compilazione notturna con frequenze diverse

In questo esempio, il trigger pianificato dell'editor classico ha due voci, producendo le compilazioni seguenti.

• Ogni lunedì - venerdì alle 3:00 UTC, i rami di compilazione che soddisfano i criteri di main filtro dei rami e releases/*

  

• Ogni domenica alle 3:00 UTC compilare il releases/lastversion ramo, anche se l'origine o la pipeline non è stata modificata

  

Il trigger pianificato YAML equivalente è:

schedules:
- cron: '0 3 * * Mon-Fri'
  displayName: M-F 3:00 AM (UTC) daily build
  branches:
    include:
    - main
    - /releases/*
- cron: '0 3 * * Sun'
  displayName: Sunday 3:00 AM (UTC) weekly latest version build
  branches:
    include:
    - /releases/lastversion
  always: true

Nella prima pianificazione, M-F 3:00 (UTC) compilazione giornaliera, la sintassi cron è 0 3 * * Mon-Fri.

• Minuti e ore: 0 3 viene eseguito il mapping a 3:00 AM UTC. Poiché il fuso orario specificato nell'editor classico è UTC, non è necessario eseguire conversioni di fuso orario.
• I giorni e i mesi vengono specificati come caratteri jolly perché questa pianificazione non specifica l'esecuzione solo in determinati giorni del mese o in un mese specifico.
• Giorni della settimana: Mon-Fri perché non è presente alcuna conversione del fuso orario, i giorni della mappa della settimana direttamente dalla pianificazione dell'editor classico. È anche possibile specificare i giorni della settimana come 1,2,3,4,5.

Nella seconda pianificazione, domenica 3:00 AM (UTC) settimanale build della versione più recente, la sintassi cron è 0 3 * * Sun.

• Minuti e ore: 0 3 viene eseguito il mapping a 3:00 AM UTC. Poiché il fuso orario specificato nell'editor classico è UTC, non è necessario eseguire conversioni di fuso orario.
• I giorni e i mesi vengono specificati come caratteri jolly perché questa pianificazione non specifica l'esecuzione solo in determinati giorni del mese o in un mese specifico.
• Giorni della settimana : Sun poiché le conversioni del fuso orario non si estendono su più giorni della settimana per la pianificazione desiderata, non è necessario eseguire alcuna conversione qui. È anche possibile specificare i giorni della settimana come 0.
• È anche necessario specificare always: true che la compilazione sia pianificata per l'esecuzione se il codice sorgente è stato aggiornato o meno.

Domande frequenti

• Si vuole che la pipeline venga eseguita solo in base alla pianificazione e non quando un utente esegue il push di una modifica in un ramo
• È stata definita una pianificazione nel file YAML. Ma non è stato eseguito. Che cosa è successo?
• Le pianificazioni YAML funzionavano correttamente. Ma, hanno smesso di lavorare ora. Ricerca per categorie eseguire il debug?
• Il codice non è stato modificato, ma viene attivata una compilazione pianificata. Perché?
• Viene visualizzata l'esecuzione pianificata nel pannello Esecuzioni pianificate. Tuttavia, non viene eseguito in quel momento. Perché?
• Pianificazioni definite nel lavoro della pipeline YAML per un ramo, ma non per l'altro. Come lo risolvo?

Si vuole che la pipeline venga eseguita solo in base alla pianificazione e non quando un utente esegue il push di una modifica in un ramo

Se si vuole che la pipeline venga eseguita solo in base alla pianificazione e non quando un utente esegue il push di una modifica a un ramo o unisce una modifica al ramo principale, è necessario disabilitare in modo esplicito i trigger di integrazione continua e aggiornamento primario predefiniti nella pipeline.

Per disabilitare i trigger di integrazione continua e aggiornamento primario predefiniti, aggiungere le istruzioni seguenti alla pipeline YAML e verificare di non aver eseguito l'override dei trigger della pipeline YAML con i trigger dell'interfaccia utente.

trigger: none
pr: none

Per altre informazioni, vedere definizione pr e definizione del trigger.

È stata definita una pianificazione nel file YAML. Ma non è stato eseguito. Che cosa è successo?

• Controllare le prossime esecuzioni pianificate da Azure Pipelines per la pipeline. È possibile trovare queste esecuzioni selezionando l'azione Esecuzioni pianificate nella pipeline. L'elenco viene filtrato in modo da mostrare solo le prossime esecuzioni nei prossimi giorni. Se questo non soddisfa le aspettative, è probabile che la pianificazione cron sia stata digitata in modo errato o che la pianificazione non sia definita nel ramo corretto. Leggere l'argomento precedente per informazioni su come configurare le pianificazioni. Rivalutare la sintassi cron. Tutte le ore per le pianificazioni cron sono in formato UTC.

• Apportare una piccola modifica semplice al file YAML ed eseguire il push dell'aggiornamento nel repository. Se si è verificato un problema durante la lettura delle pianificazioni dal file YAML in precedenza, dovrebbe essere corretto ora.

• Se nell'interfaccia utente sono definite pianificazioni, le pianificazioni YAML non vengono rispettate. Assicurarsi di non avere pianificazioni dell'interfaccia utente passando all'editor per la pipeline e quindi selezionando Trigger.

• Esiste un limite al numero di esecuzioni che è possibile pianificare per una pipeline. Altre informazioni sui limiti.

• Se non sono state apportate modifiche al codice, Azure Pipelines potrebbe non avviare nuove esecuzioni. Informazioni su come eseguire l'override di questo comportamento.

Le pianificazioni YAML funzionavano correttamente. Ma, hanno smesso di lavorare ora. Ricerca per categorie eseguire il debug?

• Se non è stato specificato always:true, la pipeline non verrà pianificata a meno che non siano presenti aggiornamenti apportati al codice. Controllare se sono state apportate modifiche al codice e come sono state configurate le pianificazioni.

• Esiste un limite al numero di volte in cui è possibile pianificare la pipeline. Controllare se questi limiti sono stati superati.

• Controllare se un utente ha abilitato più pianificazioni nell'interfaccia utente. Aprire l'editor per la pipeline e selezionare Trigger. Se sono definite pianificazioni nell'interfaccia utente, le pianificazioni YAML non verranno rispettate.

• Controllare se la pipeline è sospesa o disabilitata. Selezionare Impostazioni per la pipeline.

• Controllare le prossime esecuzioni pianificate da Azure Pipelines per la pipeline. È possibile trovare queste esecuzioni selezionando l'azione Esecuzioni pianificate nella pipeline. Se non vengono visualizzate le pianificazioni previste, apportare una piccola modifica semplice al file YAML ed eseguire il push dell'aggiornamento nel repository. Questa operazione deve risincronizzare le pianificazioni.

• Se si usa GitHub per archiviare il codice, è possibile che Azure Pipelines sia stato limitato da GitHub quando ha tentato di avviare una nuova esecuzione. Controllare se è possibile avviare manualmente una nuova esecuzione.

Il codice non è stato modificato, ma viene attivata una compilazione pianificata. Perché?

• Potrebbe essere stata abilitata un'opzione per eseguire sempre una compilazione pianificata anche se non sono presenti modifiche al codice. Se si usa un file YAML, verificare la sintassi per la pianificazione nel file YAML. Se si usano pipeline classiche, verificare se è stata selezionata questa opzione nei trigger pianificati.

• È possibile che sia stata aggiornata la pipeline di compilazione o una proprietà della pipeline. In questo modo verrà pianificata una nuova esecuzione anche se non è stato aggiornato il codice sorgente. Verificare la cronologia delle modifiche nella pipeline usando l'editor classico.

• È possibile che sia stata aggiornata la connessione al servizio usata per connettersi al repository. In questo modo verrà pianificata una nuova esecuzione anche se non è stato aggiornato il codice sorgente.

• Azure Pipelines controlla prima di tutto se sono presenti aggiornamenti al codice. Se Azure Pipelines non è in grado di raggiungere il repository o ottenere queste informazioni, verrà creata un'esecuzione informativa. Si tratta di una build fittizia per informare che Azure Pipelines non è in grado di raggiungere il repository.

• La pipeline potrebbe non avere una compilazione completa. Per determinare se pianificare una nuova compilazione o meno, Azure DevOps cerca l'ultima build pianificata completamente riuscita. Se non ne trova uno, attiva una nuova compilazione pianificata. Le compilazioni pianificate parzialmente riuscite non vengono considerate riuscite, quindi se la pipeline ha solo compilazioni parzialmente riuscite, Azure DevOps attiverà compilazioni pianificate, anche se il codice non è stato modificato.

Viene visualizzata l'esecuzione pianificata nel pannello Esecuzioni pianificate. Tuttavia, non viene eseguito in quel momento. Perché?

• Il pannello Esecuzioni pianificate mostra tutte le pianificazioni potenziali. Tuttavia, potrebbe non essere effettivamente eseguito a meno che non siano stati apportati aggiornamenti reali al codice. Per forzare l'esecuzione sempre di una pianificazione, assicurarsi di avere impostato sempre la proprietà nella pipeline YAML o di selezionare l'opzione per l'esecuzione sempre in una pipeline classica.

Pianificazioni definite nel lavoro della pipeline YAML per un ramo, ma non per l'altro. Come lo risolvo?

Le pianificazioni sono definite nei file YAML e questi file sono associati ai rami. Se si vuole pianificare una pipeline per un ramo specifico, ad esempio features/X, assicurarsi che il file YAML in tale ramo abbia la pianificazione cron definita e che disponga delle inclusioni di rami corrette per la pianificazione. Il file YAML nel features/X ramo deve avere il codice seguente schedule in questo esempio:

schedules: 
- cron: '0 12 * * 0'   # replace with your schedule
  branches: 
    include: 
    - features/X  

Per altre informazioni, vedere Considerazioni sui rami per i trigger pianificati.