Usar Actions es a fin de cuentas una manera de programar, por lo que tenemos la libertad de hacerlo como queremos, sin embargo, al igual que la escritura de código tradicional, existen una serie de buenas prácticas que mejorarán la calidad de los Workflows, su depuración y estructuración.
Un Workflow puede contener una gran cantidad de steps que ejecuten ciertos pasos, donde podríamos englobar en ciclo entero de CI/CD en un solo archivo. Si bien en la teoría es posible, en la realidad notamos que la pura ejecución tomaría horas y un solo error destruiría el ciclo entero, además de que la depuración de dicho bug contendría más ruido que resultará en más tiempo de troubleshooting.
Lo mejor es crear Workflows modulares que ejecuten una tarea específica, por esta razón creamos uno para el test, otro para el build y uno para deploy, de esta manera controlaremos cuándo se ejecutarán y si han tenido un bug detenerlo en la etapa pertinente.
Los timeouts serán limitantes de tiempo en los que si no se ejecuta un step a tiempo se determinará que ha fallado. Podemos determinar un timeout para cada job en minutos.
jobs:
configlet:
timeout-minutes: 30
runs-on: ubuntu-latest
steps:
- [...]
Es importante configurar un tiempo máximo dado que en el contexto de repos privados Actions cobra por cada minuto que ha gastado la máquina, por lo que si un step genera un bucle infinito o no es capaz de salir de un proceso se reflejará en la factura final.
Los Actions del marketplace los podemos entender como librerías de los lenguajes de programación, son utilidades hechas por terceros para facilitarnos problemas y es mejor implementarlas antes de reescribir todo el código desde 0.