I workflow di GitHub possono essere eseguiti in diverse modalità: manuale, tramite un evento come un commit, un commento ad una issue, l'aggiunta di una label o altro, come una data e ora ben precise. Per questo motivo è possibile specificare una cron expression per pianificare l'esecuzione di un workflow:

on:
  schedule:
    - cron: '0 10 * * 1,3'

Il workflow con questo trigger verrà messo in esecuzione alle 10:00 di mattina il lunedì e il mercoledì. Si può validare una POSIX cron expression tramite l'helper crontab.guru.

Sebbene questa condizione funzioni, non considera due, potenziali, problematiche: la prima riguarda il fatto che l'esecuzione non è molto precisa, la seconda è che non viene considerata la timezone, né è previsto il supporto per ora legale/solare.

Il primo caso è abbastanza particolare: sebbene noi impostiamo come orario le 10:00, l'esecuzione potrebbe non essere precisa al secondo, o addirittura al minuto. Questo è normale ed è documentato, per cui tutti i processi che devono essere eseguiti ad un timing preciso, hanno due possibilità: la prima è quella di anticipare l'esecuzione di qualche minuto e mettere uno script che calcola esattamente il timing per far partire il resto del flusso, mentre l'altra scelta ricade su sistemi basati a webhook in cui il workflow può essere invocato da sistemi esterni che possono gestire il sincronismo o l'ora per noi.

# Calcola l'orario corrente e quello target in secondi dal "giorno corrente"
target_time="10:00:00"
now=$(date +%s)
today=$(date +%Y-%m-%d)
target_epoch=$(date -d "$today $target_time" +%s)

# Calcola quanti secondi mancano
sleep_seconds=$(( target_epoch - now ))

# Tempo di attesa
sleep $sleep_seconds

# Proseguo l'esecuzione dello script...

Analizzando invece il secondo caso, bisogna sottolineare come l'orario indicato nella cron expression è basato su UTC, quindi non considera alcuna timezone, tantomeno l'ora legale/solare (anche perché molti Paesi non la supportano). Per sopperire in qualche modo a questo, sebbene non ci siano molte alternative valide, si possono inserire più cron expression:

on:
  schedule:
    # During "Central European Time" (CET): Offset from UTC: -1
    - cron: '0  9  *  11-12,1-3 1,3'
    # During "Central European Summer Time" (CEST): Offset from UTC: -2
    - cron: '0  8   *  4-10      1,3'

In entrambi i casi l'esecuzione verrà fatta alle 10 del mattino sul fuso orario 'Europe/Rome'. Il fuso orario è stato calcolato aggiungendo/sottraendo manualmente il numero di ore rispetto ad UTC, mentre l'aggiunta di una cron expression rispetto a quella di default in cui viene specificato il mese, ci aiuta a gestire anche il cambio ora legale/solare. Tuttavia, come si può notare, non tutti i giorni sono coperti e in alcuni casi potrebbe girare nel momento sbagliato. Si può fare refinement aggiungendo ulteriori cron expression per coprire anche questi casi, ma quello che è importante capire è che, al momento, non c'è una soluzione perfetta e si tratta solo di implementare workaround.