Usar Workflows pequeños
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.
Usar timeouts
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.
Cuidado con el uso de Actions de terceros
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.
Si bien usar Actions de terceros siempre será ideal, es importante fijarse en estos. Debemos revisar que el Action se encuentre en constante mantenimiento y que no ha sido abandonado hace algún tiempo (sin posibilidad de solucionar un bug que tengas), también revisar el source code y asegurar que sea de un proveedor con reputación. Un Action malicioso o defectuoso reflejará una falla de seguridad grave en nuestro proyecto y pondrá en riesgo la integridad del código.
Especificar versión de los Actions
Cuando usamos un Action debemos especificar que versión usaremos, esto normalmente se hace después del símbolo “@” con una versión (v3 por ejemplo), sin embargo, puede suceder que se sobrescriba esta versión con otro commit de manera inconsciente.
Cada commit se Git genera un hash, este hash es un identificador único por cada cambio, por lo que no importa si algo se sobrescribe de nombre, el hash original será único y podremos acceder a esta versión del Action a través del tiempo.
Si es posible, debemos acceder a la versión de los Actions con el hash indicando con un comentario a qué versión apunta.
name: Checkout code
uses: actions/checkout@a12a3943b4bdde767164f7792f33f40b04645d846 #v3
Limitar permisos de Tokens
Cuando entregamos diferentes Tokens a los Actions podemos configurar los permisos que tendrán, si no los configuramos este tendrá otro tipo de permisos (como escritura). Si un Action es comprometido, hemos dado acceso indirecto a un agente malicioso a muchos de nuestros datos.
permissions:
contents: read
Siempre es mejor limitar los permisos de nuestros tokens, de esta manera siempre estaremos blindados y lo peor que sucederá en una falla de seguridad será cambiar el proveedor y no preocuparnos por un leak de alto nivel.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?