Convalidare le modifiche con GitHub Actions

Con lo sviluppo basato su trunk, ogni modifica proposta passa attraverso una richiesta pull. Quella pull request è anche il momento giusto per eseguire controlli automatizzati. Una modifica che interrompe lo script di training non deve raggiungere maine un revisore non deve rilevare ogni errore di codice manualmente.

Flussi di lavoro, trigger e controllo qualità

Un workflow di GitHub Actions è un file YAML memorizzato nel tuo repository sotto .github/workflows/. Definisce cosa eseguire, quando eseguirlo e in quale sequenza. Un trigger (il tasto on:) dice a GitHub quando avviarlo.

Per il flusso di lavoro di convalida di Proseware, l'attivatore pull_request è adatto allo scopo. Per impostazione predefinita, viene eseguito quando una richiesta pull viene aperta, riaperta o riceve nuovi commit. Il risultato viene visualizzato come controllo dello stato nella richiesta pull.

Processi, strumenti di esecuzione e passaggi

Un flusso di lavoro organizza il lavoro in processi. Ogni processo viene eseguito in uno strumento di esecuzione, ovvero una macchina virtuale fornita da GitHub o da una gestita dall'organizzazione. Un job contiene passaggi ordinati che estraggono il repository, installano gli strumenti ed eseguono comandi.

Per il codice di training di Proseware, un processo di convalida potrebbe:

1. Consulta il repository.
2. Installare un linter (ad esempio Flake8 per Python) ed eseguirlo sugli script di addestramento.
3. Eseguire unit test(ad esempio Pytest) per verificare che le funzioni script si comportino correttamente.

Questi passaggi vengono eseguiti automaticamente in ogni richiesta pull. Nessuno deve ricordarsi di eseguirli localmente.

Esecuzione di controlli necessari

L'esecuzione automatica dei controlli è solo metà della protezione. L'altra metà consiste nel rendere questi controlli bloccanti. Nelle impostazioni di protezione dei rami, l'opzione Richiedi controlli di stato da passare prima dell'unione consente di assegnare un nome a processi specifici. Una pull request non può essere unita finché i job specificati non vengono completati con successo.

Insieme, lo sviluppo basato sul trunk e i controlli di stato richiesti costituiscono un gate di qualità: il data scientist apre una pull request, il workflow viene eseguito e il pulsante di merge rimane disabilitato finché il codice non supera i controlli.