Usare i trigger per controllare quando eseguire il flusso di lavoro
È ora disponibile un flusso di lavoro funzionante che distribuisce il file Bicep nell'ambiente Azure. Tuttavia, ogni volta che si modifica il file, il flusso di lavoro deve essere eseguito manualmente. In questa unità si apprenderà come attivare il flusso di lavoro per l'esecuzione automatica ogni volta che cambia il codice Bicep.
Nota
I comandi riportati in questa unità vengono illustrati per spiegare i concetti. Non eseguire ancora i comandi. Presto sarà possibile provare quanto appreso.
Che cos'è un trigger di flusso di lavoro?
Un trigger del flusso di lavoro è una condizione che, se soddisfatta, esegue automaticamente il flusso di lavoro in base alle regole create. È possibile impostare i trigger per eseguire il flusso di lavoro a intervalli pianificati. È anche possibile impostare i trigger per eseguire il flusso di lavoro ogni volta che cambia un file nel repository. Si potrebbe scegliere la seconda opzione perché è consigliabile eseguire tutti i test e i passaggi di distribuzione ogni volta che il codice viene modificato.
Se non si usa un trigger automatico, un utente potrebbe apportare una modifica a un file Bicep e persino eseguirne il commit e il push nel repository, ma se dimentica di eseguire il flusso di lavoro, vi sarà una differenza tra le definizioni delle risorse nel file Bicep e le risorse distribuite nell'ambiente Azure. Si supponga che vengano eseguiti un altro paio di commit e push, ma non distribuiti. Se durante una di queste modifiche qualcuno introduce un errore o una configurazione errata nel file Bicep, potrebbe essere difficile rilevare l'errore tra i diversi commit che vengono distribuiti contemporaneamente in un secondo momento. Dopo un po' si rischia di non potersi più fidare che il codice Bicep contenga una rappresentazione fedele dell'infrastruttura, con conseguente perdita di valore.
Quando si configura il flusso di lavoro per l'esecuzione ogni volta che si aggiornano i file, nel momento in cui viene eseguito il push delle modifiche viene avviata l'esecuzione del flusso di lavoro. Si ottiene un feedback immediato sulla validità della modifica e si può essere certi che l'ambiente di produzione sia sempre aggiornato.
Trigger di evento push
Un tipo comune di trigger è un trigger di evento push, noto anche come trigger di integrazione continua o trigger CI. Quando si usa un trigger di evento push, ogni volta che si apporta una modifica a un ramo specifico, viene eseguito il flusso di lavoro. Se si eseguono il commit e il push di una modifica in un ramo diverso, il flusso di lavoro non viene attivato e non viene eseguito. È comune usare questo tipo di trigger sul ramo predefinito, o principale, con questo codice:
on:
push:
branches:
- main
Trigger per la modifica di più rami
È possibile configurare trigger per eseguire il flusso di lavoro in un ramo specifico o in set di rami. Si supponga, ad esempio, di creare rami di versione contenenti il codice che verrà distribuito per una versione specifica del progetto. È possibile usare nomi di ramo come release/v1, release/v2 e così via. Si vuole eseguire il flusso di lavoro ogni volta che il codice viene modificato in un ramo che inizia con il nome release/. È possibile usare un carattere jolly **:
on:
push:
branches:
- main
- 'release/**'
È anche possibile escludere rami specifici. Si supponga di collaborare con i membri del team nel progetto. I colleghi creano rami di funzionalità per provare le proprie idee nei file Bicep. Tutti i rami di funzionalità hanno nomi come feature/add-database, feature/improve-performance e così via. Si vuole eseguire automaticamente il flusso di lavoro in tutti i rami, a eccezione dei rami di funzionalità creati dai colleghi. Usando la proprietà exclude, si garantisce che il flusso di lavoro non venga attivato automaticamente per le modifiche ai rami di funzionalità:
on:
push:
branches-ignore:
- 'feature/**'
Nota
Per escludere determinati rami, usare il carattere !. Si supponga di voler attivare il flusso di lavoro per il ramo principale e tutti i rami di versione, a eccezione delle versioni alfa. Per esprimere questa condizione, è possibile usare il carattere !:
on:
push:
branches:
- main
- 'release/**'
- '!release/**-alpha'
Poiché non è possibile usare branches e branches-ignore nello stesso trigger, il carattere ! offre la flessibilità necessaria per controllare il comportamento del trigger.
Filtri di percorso
In alcuni casi nel repository sono presenti file non correlati alla distribuzione. Ad esempio, nel repository potrebbero essere presenti una cartella deploy contenente il codice Bicep e una sottocartella docs che contiene i file della documentazione. Si vuole attivare il flusso di lavoro quando un utente apporta una modifica a uno dei file Bicep nella cartella deploy, ma non lo si vuole attivare se un utente modifica solo un file di documentazione. Per configurare un trigger per rispondere alle modifiche in una cartella specifica nel repository, è possibile usare un filtro per percorsi:
on:
push:
paths:
- 'deploy/**'
- '!deploy/docs/**'
Se qualcuno esegue il commit di una modifica che aggiorna solo un file di documentazione, il flusso di lavoro non viene eseguito. Ma se viene modificato un file Bicep o anche se viene modificato un file Bicep in aggiunta a un file di documentazione, il trigger esegue il flusso di lavoro.
Nota
È anche possibile usare paths-ignore, che funziona in modo simile alla parola chiave branches-ignore. Non è tuttavia possibile usare paths e paths-ignore nello stesso trigger.
Pianificare l'esecuzione automatica del flusso di lavoro
È possibile eseguire il flusso di lavoro in base a una pianificazione impostata e non in risposta a una modifica del file. Ad esempio, è possibile eseguire un rilascio notturno del codice Bicep o distribuire automaticamente un ambiente di test ogni mattina. Usare la parola chiave schedule e impostare la frequenza usando un'espressione cron:
on:
schedule:
- cron: '0 0 * * *'
Nota
Un'espressione cron è una sequenza di caratteri formattata in modo speciale che specifica la frequenza con cui deve verificarsi un evento. In questo esempio 0 0 * * * significa esecuzione ogni giorno a mezzanotte ora UTC.
In un file YAML è necessario racchiudere tra virgolette le stringhe che contengono il carattere *, ad esempio le espressioni cron.
L'evento di pianificazione esegue sempre il flusso di lavoro nel ramo predefinito del repository.
Usare più trigger
È possibile combinare trigger e pianificazioni, come in questo esempio:
on:
push:
branches:
- main
schedule:
- cron: '0 0 * * *'
Quando si creano un trigger di ramo e un trigger pianificato nello stesso flusso di lavoro, il flusso di lavoro viene eseguito ogni volta che un file viene modificato nel ramo impostato nel trigger e in base alla pianificazione impostata. In questo esempio il flusso di lavoro viene eseguito ogni giorno a mezzanotte ora UTC e anche ogni volta che viene eseguito il push di una modifica nel ramo main.
Suggerimento
È consigliabile impostare trigger per ogni flusso di lavoro. Se non si impostano i trigger, per impostazione predefinita il flusso di lavoro viene eseguito automaticamente ogni volta che un file cambia in qualsiasi ramo, che spesso non è un approccio desiderabile.
Trigger webhook
GitHub fornisce anche eventi webhook, che vengono eseguiti automaticamente quando si verificano determinati eventi nel repository. Questi eventi includono la creazione di un ramo, l'aggiornamento dei problemi di GitHub o le modifiche alle richieste pull. In genere, questi eventi non richiedono l'esecuzione del flusso di lavoro di distribuzione Bicep, ma si potrebbero eseguire altre operazioni di automazione.
Controllo della concorrenza
Per impostazione predefinita, GitHub Actions consente l'esecuzione simultanea di più istanze del flusso di lavoro. Ciò può verificarsi quando si eseguono più commit a un ramo in un breve periodo di tempo o se un'esecuzione precedente non è terminata quando si attiva la prossima pianificazione.
In alcune situazioni, la presenza di più esecuzioni simultanee del flusso di lavoro non è un problema. Quando si utilizzano i flussi di lavoro di distribuzione, può essere difficile assicurarsi che le esecuzioni del flusso di lavoro non sovrascrivano le risorse o la configurazione di Azure in modi non previsti.
Per evitare questi problemi, è possibile applicare il controllo della concorrenza. Usare la parola chiave concurrency, quindi specificare una stringa coerente in tutte le esecuzioni per il flusso di lavoro. Si tratta in genere di una stringa hardcoded, come in questo esempio:
concurrency: MyWorkflow
GitHub Actions quindi garantisce che si attenda il completamento di qualsiasi esecuzione attiva del flusso di lavoro prima di iniziare una nuova esecuzione.