Condividi tramite


Configurare gli orari 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 programmati avviano la tua pipeline in base a un orario, ad esempio una build 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 Triggers in Azure Pipelines.

È possibile combinare trigger pianificati e basati su eventi nelle pipeline, ad esempio per convalidare la compilazione ogni volta che viene eseguito 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 i trigger CI e PR abilitati per impostazione predefinita. Per informazioni sulla disabilitazione dei trigger predefiniti, vedere Trigger in Azure Pipelines e navigare alla sezione relativa al tipo di repository.

Attivatori pianificati

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 attivatori pianificati YAML e attivatori pianificati definiti dall'interfaccia utente, vengono eseguiti solo gli attivatori 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 le impostazioni dell'interfaccia utente ignorano i trigger pianificati YAML.

I trigger pianificati configurano una pipeline per l'esecuzione in base a una pianificazione definita usando 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 or pipeline settings changes since the last successful scheduled run. The default is false.
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 or pipeline settings 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.

Considerazioni sul ramo relativamente ai trigger pianificati

Gli attivatori pianificati vengono valutati per un ramo quando si verificano i seguenti eventi.

  • 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 quel ramo specifico.

Ad esempio, viene creata una pipeline con la pianificazione seguente e questa versione del file YAML viene archiviata nel ramo main. Questa pianificazione compila il ramo main 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 ramo new-feature, non vengono apportate modifiche alle compilazioni pianificate e il ramo new-feature non viene compilato usando un trigger pianificato.

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

# 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 base a maine quindi release viene aggiunto ai filtri di ramo nel file YAML nel ramo main, ma non nel ramo release appena creato.

# 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 dei rami nel ramo main, ma non ai filtri dei rami nel ramo release, il ramo release non verrà compilato in base a tale pianificazione. Solo quando il ramo release viene aggiunto ai filtri di ramo nel file YAML nel ramo di rilascio la compilazione pianificata verrà aggiunta all'utilità di pianificazione.

Considerazioni sui batch per i trigger pianificati

Nota

La proprietà batch è disponibile in Azure DevOps Server 2022.1 e versioni successive.

La proprietà batch configura se eseguire la pipeline quando l'esecuzione pianificata in precedenza è in corso. Quando batch è true, una nuova esecuzione della pipeline non verrà avviata a causa della pianificazione se è ancora in corso un'esecuzione della pipeline precedente. Il valore predefinito è false.

La proprietà batch è interessata dall'impostazione della proprietà always. Quando always è true, la pipeline viene eseguita in base alla pianificazione cron, anche quando batch è true e viene eseguita un'esecuzione in corso.

Sempre Gruppo Comportamento
false false La pipeline viene eseguita solo se è presente una modifica rispetto all'ultima esecuzione pianificata della pipeline, anche se è in corso un'esecuzione in corso dall'ultimo trigger pianificato.
false true La pipeline viene eseguita solo se è presente una modifica rispetto all'ultima esecuzione pianificata della pipeline riuscita e non c'è alcuna esecuzione pianificata della pipeline in corso.
true false La pipeline viene eseguita secondo la programmazione cron.
true true La pipeline viene eseguita in base al programma cron anche se è in corso un'esecuzione.

Variabile Build.CronSchedule.DisplayName

Nota

La variabile Build.CronSchedule.DisplayName è disponibile in Azure DevOps Server 2022.1 e versioni successive.

Quando una pipeline è in esecuzione a causa di un trigger pianificato cron, la variabile di Build.CronSchedule.DisplayName predefinita contiene il 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 variabile Build.CronSchedule.DisplayName in una condizione di processo o fase per determinare se eseguire il processo o la 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 schedules.cron examples.

Esempi

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 rami releases/*, ad eccezione dei rami in releases/ancient/*.

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

Nota

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

Per altri esempi, vedere Migrazione dall'editor classico.

Sintassi Cron

Ogni espressione cron del trigger pianificato di Azure Pipelines è un'espressione con cinque voci, separate da spazi, 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
Orario 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 in inglese, prime tre lettere dei nomi inglesi

I valori possono essere nei formati seguenti.

Formato Esempio Descrizione
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 o 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
Costruire 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 * * * o 0 9-21/6 * * *

Per altre informazioni sui formati supportati, consultare l'Espressione Crontab .

Usare GitHub Copilot per creare un'espressione cron

È possibile ottenere assistenza per intelligenza artificiale da GitHub Copilot per creare espressioni cron o convertire espressioni cron esistenti dal fuso orario locale all'ora UTC.

Le pianificazioni cron di Azure Pipelines sono definite in formato UTC, quindi le pianificazioni come Build ogni lunedì, mercoledì e venerdì alle 18:00 devono essere create usando la sintassi cron e convertite dal fuso orario locale all'ora UTC.

Personalizzare le istruzioni seguenti per creare espressioni cron o convertire espressioni cron in formato UTC dal fuso orario usato per creare le espressioni.

Nell'esempio seguente, viene richiesto a Copilot di creare una pianificazione cron UTC per eseguire ogni lunedì, mercoledì e venerdì alle 18:00 secondo il fuso orario orientale degli Stati Uniti.

Build a UTC cron expression for Monday, Wednesday, and Friday at 6:00 PM Eastern Standard Time

Se si dispone già di un'espressione cron nel fuso orario locale, è possibile chiedere a Copilot di convertirla in formato UTC. In questo esempio, una pianificazione cron per la costruzione ogni lunedì, mercoledì e venerdì alle 18:00 (0 18 * * Mon,Wed,Fri) ora standard orientale viene convertita in UTC.

Convert the following cron expression from Eastern Standard Time to UTC: 0 18 * * Mon,Wed,Fri

La conversione di un'espressione cron in utc potrebbe richiedere la modifica dei giorni della settimana nell'espressione. Nell'esempio seguente, si chiede a Copilot di creare una pianificazione cron UTC per la compilazione da lunedì a venerdì alle 12:30 Central European Standard Time. L'ora solare centrale europea è in anticipo rispetto all'ora UTC, quindi l'espressione risultante inizia la domenica sera invece che all'inizio del lunedì mattina e termina giovedì.

Build a UTC cron expression for Monday through Friday at 12:30 AM Central European Standard Time

Per ottenere altri dettagli sull'espressione cron generata da Copilot, è possibile chiedere a Copilot di fornire una spiegazione dell'espressione cron generata nel prompt.

Build a UTC cron expression for Monday through Friday at 12:30 AM Central European Standard Time and explain the different parts of the cron expression

Copilot è alimentato dall'IA, quindi sono possibili sorprese ed errori. Per altre informazioni, vedere Domande frequenti sull'uso generale di Copilot.

Visualizzazione esecuzioni pianificate

È possibile visualizzare un'anteprima delle imminenti compilazioni pianificate scegliendo esecuzioni pianificate dal menu di scelta rapida nella pagina dei dettagli della tua 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 vista Esecuzioni pianificate.

Menu esecuzioni pianificate

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

esecuzioni pianificate

In questo esempio vengono visualizzate le esecuzioni pianificate per il programma seguente.

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

Le esecuzioni pianificate finestre 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.

Nota

Se si aggiorna la pianificazione per una pipeline in esecuzione, la visualizzazione delle esecuzioni pianificate non viene aggiornata con la nuova pianificazione fino al completamento della pipeline in corso.

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. Ad esempio, considera che hai pianificato l'esecuzione di una pipeline ogni notte alle 21:00. Durante i giorni feriali, fai il push di varie modifiche al codice. La pipeline viene eseguita secondo il programma. 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.

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

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

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

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

  • Ogni lunedì dal venerdì alle 3:00 (fuso orario UTC + 5:30), compilare i rami che soddisfano i criteri di filtro del ramo features/india/*.

    attivatore pianificato UTC+5:30 fuso orario

  • Dal lunedì al venerdì alle 3:00 (fuso orario UTC - 5:00), compilare i rami che soddisfano i criteri di filtro del ramo features/nc/*

    trigger pianificato fuso orario UTC -5:00

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 (UTC + 5:30), compilazione 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 di 3:00 AM per arrivare all'ora UTC desiderata per specificare per il trigger YAML. È possibile ottenere assistenza sull'intelligenza artificiale da GitHub Copilot per creare l'espressione cron.
  • I giorni e i mesi vengono specificati come caratteri jolly perché questo programma non specifica l'esecuzione solo in certi giorni del mese o in un mese particolare.
  • Giorni della settimana - Sun-Thu - a causa della conversione del fuso orario, per fare in modo che le nostre build vengano eseguite alle 3:00 nel fuso orario dell'India (UTC + 5:30), dobbiamo specificare l'avvio il giorno precedente nell'ora UTC. È anche possibile specificare i giorni della settimana come 0-4 o 0,1,2,3,4.

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

  • Minuti e ore - 0 8 - è mappato su 8:00 AM UTC. Poiché il fuso orario specificato nell'editor classico è UTC - 5:00, è necessario aggiungere 5 ore all'ora di compilazione desiderata delle 3:00 del mattino per determinare l'ora UTC corretta da specificare nel trigger YAML. È possibile ottenere assistenza sull'intelligenza artificiale da GitHub Copilot per creare l'espressione cron.
  • I giorni e i mesi vengono specificati come caratteri jolly perché questo programma 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 tengono conto dell'ora legale.

Suggerimento

Quando si usano le 3 lettere dei giorni della settimana e si desidera un intervallo di più giorni fino a domenica, domenica deve essere considerata il primo giorno della settimana, ad esempio per una pianificazione a 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, generando le seguenti compilazioni.

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

    Frequenza del trigger pianificato 1.

  • Ogni domenica alle 3:00 UTC, si compila il ramo releases/lastversion, anche se l'origine o la pipeline rimangono invariati.

    frequenza di trigger pianificata 2.

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 compilazione giornalieraM-F 3:00 (UTC), la sintassi cron è 0 3 * * Mon-Fri.

  • Minuti e ore - 0 3 - Corrisponde a 3:00 AM UTC. Poiché il fuso orario specificato nell'editor classico è UTC, non è necessario eseguire alcuna conversione del fuso orario.
  • I giorni e i mesi vengono specificati come caratteri jolly perché questo programma non specifica l'esecuzione solo in determinati giorni del mese o in uno specifico mese.
  • Giorni della settimana - Mon-Fri - perché, non essendoci conversione del fuso orario, i giorni della settimana corrispondono direttamente alla programmazione dell'editor classico. È anche possibile specificare i giorni della settimana come 1,2,3,4,5.

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

  • Minuto e ora - 0 3 - È associato a 3:00 AM UTC. Poiché il fuso orario specificato nell'editor classico è UTC, non è necessario eseguire alcuna conversione del fuso orario.
  • I giorni e i mesi vengono specificati come caratteri jolly perché questo programma non prevede l'esecuzione solo in determinati giorni del mese o in mesi specifici.
  • 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.
  • È inoltre necessario specificare always: true poiché la compilazione è pianificata per l'esecuzione indipendentemente dal fatto che il codice sorgente sia 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

Se si desidera che la pipeline venga eseguita solo in base alla pianificazione e non quando qualcuno fa il push di una modifica in un ramo o unisce una modifica al ramo principale, è necessario disabilitare esplicitamente i trigger CI e PR predefiniti nella pipeline.

Per disabilitare i trigger CI e PR predefiniti, aggiungere le istruzioni seguenti alla pipeline YAML e verificare di non aver sostituito i trigger della pipeline YAML con dei trigger dell'interfaccia grafica utente.

trigger: none
pr: none

Per ulteriori informazioni, consultare definizione pr e definizione trigger.

È stata definita una pianificazione nel file YAML. Ma non ha funzionato. 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 per mostrare solo le sessioni imminenti 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. Rivaluta la sintassi cron. Tutti gli orari per le pianificazioni cron sono in 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 di .

  • Se non sono state apportate modifiche al codice, Azure Pipelines potrebbe non avviare nuove esecuzioni. Scopri come modificare questo comportamento.

Le pianificazioni YAML funzionavano correttamente. Ma, hanno smesso di lavorare ora. Come si esegue il debug di questa operazione?

  • 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 hai configurato le pianificazioni.

  • È previsto un limite sul numero di volte in cui è possibile pianificare la tua 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 Triggers. Se sono definite pianificazioni nell'interfaccia utente, le pianificazioni YAML non verranno rispettate.

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

  • Controlla le prossime esecuzioni che Azure Pipelines ha pianificato per la tua pipeline. Puoi trovare queste esecuzioni selezionando l'azione "Esecuzioni pianificate" nella tua 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é?

  • È possibile che sia stata abilitata un'opzione per sempre eseguire una compilazione pianificata anche se non sono presenti modifiche al codice. Se si usa un file YAML, verificare la sintassi della pianificazione nel file YAML. Se usi pipeline classiche, verifica se hai selezionato 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 riesce a raggiungere il repository o ottenere queste informazioni, creerà 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 build completamente riuscita. 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.

Visualizzo l'esecuzione pianificata nel pannello delle Esecuzioni pianificate. Tuttavia, non viene eseguito a quell'ora. 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 una pianificazione a essere sempre eseguita, verificare di aver impostato la proprietà sempre nella pipeline YAML o di selezionare l'opzione per l'esecuzione sempre in una pipeline classica.

Pianificazioni definite nella pipeline YAML funzionano per un ramo, ma non per l'altro. Com'è possibile risolvere il problema?

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 ramo features/X deve avere il seguente schedule in questo esempio:

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

Per altre informazioni, vedere Considerazioni sul ramo per i trigger pianificati.