Tempo fa ho modificato ulteriormente il comportamento dello script di azioni per il backup della New Music Friday di Spotify per cercare di rispondere a un’esigenza reale: cosa fare in caso di fallimento del backup? Domanda lecita considerando che – spesso e senza apparente motivazione e/o riproducibilità – la prima volta che chiedo a GitHub Actions di occuparsi del backup della playlist del venerdì tramite il mio script Python, questo ottiene un bel dito medio dalle API del noto provider di musica in streaming. Il tutto sarebbe anche lecito se non fosse che al secondo tentativo, dal nulla, questo magari è in grado di portare a termine il compito come nulla fosse.

È per questo motivo ho deciso di studiare la possibilità di “tornare indietro in caso di fallimento“, di prendermi un attimo di tempo (calcolato in base all’esperienza pregressa con gli altri tentativi falliti e riattivati manualmente dal sottoscritto) e quindi riprovare, con successo stavolta. Ti dico molto rapidamente come ho modificato il comportamento del file YML e quindi dello script Python per lavorare insieme a GitHub Actions.

run-if-failed

Ci sono una serie di articoli e riferimenti (tra forum, blog e altro) da cui ho preso violentemente spunto e per questo motivo ringrazio infinitamente tutti coloro che hanno speso parole in merito che mi hanno messo sulla giusta via, o per lo meno su una via che in fondo è servita a fare ciò che volevo, trovi tutto in fondo a questo articolo.

La sostanza è semplice: GitHub Actions, lo script YML, è in grado di accorgersi se quanto richiesto va a buon fine o meno, bisogna per questo motivo approfittare di questa capacità per determinare la necessità di far girare ulteriori operazioni in caso di fallimento, è il motivo per il quale si utilizza il run-if-failed, ed è esattamente ciò che ho fatto in uscita dal set di istruzioni nativamente pubblicate e funzionanti su GitHub e Actions.

run-if-failed:
    runs-on: ubuntu-latest
    needs: [execute-cron]
    if: always() && (needs.execute-cron.result == 'failure')
    steps:
      - name: Sleep Action
        uses: juliangruber/sleep-action@v1.0.1
        with:
          time: 10m

La run-if-failed partirà solo ed esclusivamente dopo la execute-cron (il blocco di istruzioni che si occupa di fare il backup della playlist, che in teoria dovrebbe funzionare al primo colpo), che è infatti obbligatoria senza la quale questo secondo blocco di istruzioni non verrà mai eseguito. A completare il giro di check ci penserà quel if: always() && (needs.execute-cron.result == 'failure') che si occuperà proprio di controllare che lo stato d’uscita del blocco di istruzioni iniziale dia come risultato un failure. È a questo punto che si ingaggia ciò che viene subito dopo nel file YML.

La “Sleep Action” (questa: github.com/juliangruber/sleep-action) si occupa di far partire un conto alla rovescia di 10 minuti, dopo i quali lo script YML indicherà a GitHub Actions di rifare le stesse identiche cose che aveva provato a eseguire 10 minuti prima. Perché 10 minuti? Perché è quasi sempre la risposta alla domanda “Quando devo attendere prima di riprovare e sperare vada a buon fine?“. Nel caso in cui la risposta fosse sbagliata, poco male, ci saranno ulteriori 10 minuti di attesa prima di provarci ancora, e via così fino a quando da quel loop si uscirà vittoriosi (o definitivamente sconfitti, speriamo mai).

Come committare solo in caso di novità

Non è lo specifico caso del repository dedicato al backup della Spotify New Music Friday Italia (ci si sposta sull’altro repository, quello dedicato a Netflix – github.com/gioxx/netflix-leaving – del quale spero di poterti parlare presto), ma è una domanda altrettanto lecita. Va tutto bene, lo script fa il suo lavoro e poi al termine, in caso di modifiche, c’è qualcosa che viene committato (uso diverse Actions già pronte, ma in questo caso sto parlando di questa: github.com/stefanzweifel/git-auto-commit-action).

Cosa fare se però non ci sono modifiche ai file e quindi non c’è nulla da committare? L’azione di Stefan Zweifel fallisce se non c’è nulla da committare, io voglio evitarlo.

Ho quindi pensato di utilizzare le variabili d’ambiente e fare in maniera che uno script Python ne scrivesse una per poterla far leggere allo script YML, durante l’esecuzione delle istruzioni date in pasto a GitHub Actions. Nel file Python ho quindi inserito un controllo che produce un “None“ (nella variabile Expiring) nel caso in cui nulla cambi:

print("No titles from your list are leaving Netflix")
    try:
        env_file = os.getenv('GITHUB_ENV')
        with open(env_file, "a") as ghenv:
            ghenv.write("Expiring=None")

e un check sul file di istruzioni YML che se ne renderà conto, annullando eventualmente tutto ciò che viene dopo:

- name: Commit changes
  id: commit_changes
  if: env.Expiring != 'None'
  uses: stefanzweifel/git-auto-commit-action@v4

Il controllo potrà essere utilizzato ovunque tu voglia ed è facile far comunicare uno script Python (ma non solo) con le variabili d’ambiente di GitHub, anche se neanche si sono mai conosciuti nella loro vita ;-)

Ora non resta che trovare il tempo (!) di aggiornare i file README dei repository GitHub per spiegare anche questa cosa a chi vuole forkare e farsi il suo repository. Se hai dubbi, l’area commenti è giusto un colpo di scroll più in basso, usala :-)

#StaySafe

Immagine di copertina JESHOOTS.COM on Unsplash

Credits:
medium.com/testableapple/how-to-re-run-only-failed-jobs-on-github-actions-b79b13d1ceb2
github.community/t/run-step-if-file-exists/16445/6
github.community/t/run-github-actions-job-only-if-previous-job-has-failed/174786/2
github.com/alteral/re-run-only-failed-jobs-on-github-actions