Uso de desencadenadores para controlar cuándo se ejecuta el flujo de trabajo
Ahora tiene un flujo de trabajo en funcionamiento que implementa el archivo de Bicep en el entorno de Azure. Sin embargo, cada vez que cambia el archivo, debe ejecutar manualmente el flujo de trabajo. En esta unidad, aprenderá a desencadenar el flujo de trabajo para que se ejecute automáticamente cada vez que cambie el código de Bicep.
Nota:
Los comandos de esta unidad se muestran para ilustrar conceptos. No los ejecute todavía. Pronto va a practicar lo que aprenderá aquí.
¿Qué es un desencadenador de un flujo de trabajo?
Un desencadenador de un flujo de trabajo es una condición que, cuando se cumple, ejecuta automáticamente el flujo de trabajo en función de las reglas que cree. Puede establecer desencadenadores para ejecutar el flujo de trabajo a intervalos programados. También puede establecer desencadenadores para ejecutar el flujo de trabajo cada vez que cambie un archivo del repositorio. Es posible que elija la segunda opción, porque es recomendable ejecutar todas las pruebas y los pasos de implementación cada vez que alguien cambie el código.
Si no usa un desencadenador automático, alguien podría realizar un cambio en un archivo de Bicep e incluso confirmarlo e insertarlo en el repositorio, pero si olvidan ejecutar el flujo de trabajo, habrá una diferencia entre las definiciones de recursos en el archivo de Bicep y los recursos que se implementan en su entorno de Azure. Supongamos que se realizan un par de confirmaciones e inserciones más, pero no se implementan. Si alguien introduce un error o una configuración incorrecta en el archivo de Bicep en uno de estos cambios, puede ser difícil realizar un seguimiento del error entre las múltiples confirmaciones que se implementen más adelante a la vez. Después de un tiempo, no confiará en que el código de Bicep represente realmente la infraestructura y su valor se ha deteriorado.
Si configura el flujo de trabajo para que se ejecute cada vez que actualice los archivos, el flujo de trabajo comienza a ejecutarse en el momento en el que se inserten los cambios. Obtiene comentarios instantáneos sobre la validez del cambio y puede asegurarse de que el entorno de producción siempre está actualizado.
Desencadenadores de eventos de inserción
Un tipo de desencadenador común es un desencadenador de evento de inserción, también denominado desencadenador de integración continua o desencadenador de CI. Si usa un desencadenador de evento de inserción, cada vez que se realiza un cambio en una rama específica, se ejecuta el flujo de trabajo. Si confirma e inserta un cambio en otra rama, no se desencadena el flujo de trabajo y no se ejecuta. Es habitual usar este tipo de desencadenador en la rama principal o predeterminada, con este código:
on:
push:
branches:
- main
Desencadenador cuando cambian varias ramas
Puede configurar desencadenadores para ejecutar el flujo de trabajo en una rama específica o en conjuntos de ramas. Por ejemplo, supongamos que crea ramas de versión que contienen el código que va a implementar para una versión específica del proyecto. Puede usar nombres de rama como release/v1, release/v2, etc. Puede ejecutar el flujo de trabajo cada vez que el código cambie en una rama que comience con el nombre release/. Puede usar el carácter comodín **:
on:
push:
branches:
- main
- 'release/**'
También puede excluir ramas concretas. Supongamos que está colaborando con los miembros del equipo en el proyecto. Sus compañeros crean ramas de características para probar sus ideas en archivos de Bicep. Todas las ramas de características tienen nombres como feature/add-database, feature/improve-performance, etc. Quiere ejecutar el flujo de trabajo automáticamente en todas las ramas excepto para las ramas de características que creen sus compañeros. Al usar la propiedad exclude, se asegura de que el flujo de trabajo no se desencadene automáticamente por cambios en las ramas de características:
on:
push:
branches-ignore:
- 'feature/**'
Nota:
Para excluir determinadas ramas, use el carácter !. Supongamos que quiere desencadenar el flujo de trabajo para la rama principal y todas las ramas de versión, excepto las versiones alfa. Puede usar el carácter ! para expresar esto:
on:
push:
branches:
- main
- 'release/**'
- '!release/**-alpha'
No puede usar branches y branches-ignore juntos en un desencadenador, por lo que el carácter ! le proporciona flexibilidad para controlar el comportamiento del desencadenador.
Filtros de ruta de acceso
A veces, tiene archivos en el repositorio que no están relacionados con la implementación. Por ejemplo, es posible que tenga en el repositorio una carpeta deploy que contenga el código de Bicep y una subcarpeta docs que contenga los archivos de la documentación. Supongamos que desea desencadenar el flujo de trabajo cuando alguien realice un cambio en cualquiera de los archivos de Bicep de la carpeta deploy, pero no quiere desencadenar el flujo de trabajo si alguien cambia solo un archivo de la documentación. Para configurar un desencadenador que responda a los cambios de una carpeta específica del repositorio, puede usar un filtro de ruta de acceso:
on:
push:
paths:
- 'deploy/**'
- '!deploy/docs/**'
Si alguien confirma un cambio que solo actualiza un archivo de la documentación, el flujo de trabajo no se ejecuta. Pero si alguien cambia un archivo de Bicep, o incluso si cambia un archivo de Bicep y un archivo de la documentación, el desencadenador ejecuta el flujo de trabajo.
Nota:
También puede usar paths-ignore, que funciona de manera parecida a la palabra clave branches-ignore. Sin embargo, no puede usar paths y paths-ignore en el mismo desencadenador.
Programación del flujo de trabajo para que se ejecute automáticamente
Puede ejecutar el flujo de trabajo según una programación establecida y no en respuesta a un cambio en un archivo. Por ejemplo, puede ejecutar una versión del código de Bicep por la noche o implementar automáticamente un entorno de prueba cada mañana. Use la palabra clave schedule y especifique la frecuencia con la expresión cron:
on:
schedule:
- cron: '0 0 * * *'
Nota:
Una expresión CRON es una secuencia de caracteres con formato especial que especifica la frecuencia con la que debe ocurrir algo. En este ejemplo, 0 0 * * * significa ejecutarse todos los días a medianoche UTC.
En un archivo de YAML, debe entrecomillar las cadenas que contengan el carácter *, como las expresiones cron.
El evento de programación siempre ejecuta el flujo de trabajo en la rama predeterminada del repositorio.
Uso de varios desencadenadores
Puede combinar desencadenadores y programaciones, como en este ejemplo:
on:
push:
branches:
- main
schedule:
- cron: '0 0 * * *'
Cuando se crean un desencadenador de rama y un desencadenador programado en el mismo flujo de trabajo, el flujo de trabajo se ejecuta cada vez que cambia un archivo en la rama especificada en el desencadenador y según la programación establecida. En este ejemplo, el flujo de trabajo se ejecuta todos los días a medianoche (UTC) y también siempre que se inserta un cambio en la rama principal.
Sugerencia
Es recomendable especificar desencadenadores para cada flujo de trabajo. Si no lo hace, el flujo de trabajo se ejecuta automáticamente de forma predeterminada cada vez que se produce algún cambio en un archivo de cualquier rama, que no suele ser lo deseado.
Desencadenadores de webhook
GitHub también proporciona eventos de webhook, que se ejecutan automáticamente cuando suceden determinados eventos en el repositorio. Estos eventos pueden ser que alguien crea una rama, actualizaciones de problemas de GitHub o cambios en las solicitudes de extracción. Por lo general, estos eventos no requieren que se ejecute el flujo de trabajo de implementación de Bicep, pero puede ejecutar otra automatización en su lugar.
Control de simultaneidad
De forma predeterminada, Acciones de GitHub permite que varias instancias del flujo de trabajo se ejecuten simultáneamente. Esto puede ocurrir cuando realiza varias confirmaciones en una rama en un breve período de tiempo, o si una ejecución anterior no ha finalizado cuando se desencadena la siguiente programación.
En algunas situaciones, tener varias ejecuciones simultáneas del flujo de trabajo no es un problema. Cuando se trabaja con flujos de trabajo de implementación, sin embargo, puede ser difícil asegurarse de que las ejecuciones de flujo de trabajo no sobrescriban los recursos o la configuración de Azure de maneras que no se esperan.
Para evitar estos problemas, puede aplicar el control de simultaneidad. Use la palabra clave concurrency y especifique una cadena coherente en todas las ejecuciones del flujo de trabajo. Normalmente es una cadena codificada de forma rígida, como en este ejemplo:
concurrency: MyWorkflow
Acciones de GitHub garantiza que espera a que se complete cualquier ejecución de flujo de trabajo activa antes de iniciar una nueva ejecución.