En algunos casos se espera que un flujo de trabajo sea ejecutado una única vez (e.g. despliegues) o ejecutar la versión más actual (e.g. el último commit de un Pull Request) pero a simple vista no es tan sencillo de configurar utilizando GitHub Actions.
El gasto de actions es una de las razones principales por la se requiere optimizar al máximo la configuración de los flujos de trabajos. Una de las tareas más comunes que se quiere evitar es la de ejecutar multiples veces flujos cada vez que realizamos una acción.
Para este caso:
on:
push:
branches:
- staging # Despliegue de aplicación
pull_request:
branches:
- staging # Validaciones por cada commit agregado en un Pull Request
Para cualquiera de las opciones anteriores, se espera que sólo se tenga en cuenta la versión más reciente de los cambios y no se requiere que se ejecuten todos los flujos que se encolen.
- Actions creados por terceros: cancel-workflow-action es una alternativa que funciona pero nunca va a ser tan respaldada como una "opción nativa" porque un action creado por un tercero requiere más configuración y tiempo de ejecución. Ésta fue una gran opción hasta el inicio del año 2021 ya que no se tenia una configuración del propio GitHub. Por eso es una opción valida.
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Cancel Previous Runs
uses: styfle/cancel-workflow-action@0.9.1
with:
access_token: ${{ github.token }}
...
Agregando el action cancel-workflow-action
como un paso en el job será suficiente para ejecutar una única vez el job por flujo. Se utiliza access_token
(credencial generada en GitHub) para acceder a la API de GitHub y consultar información sobre ejecuciones activas y poder cancelarlas de ser necesario.
Opción efectiva pero "costosa" en tiempo y recursos.
- Configuración del flujo de trabajo (Recomendada): Establecer las opciones de Concurrencia.
concurrency:
group: ci-${{ github.ref }} # Grupo filtrado por nombre de la rama github.ref
cancel-in-progress: true
Concurrencia se refiere a la cantidad de ejecuciones del mismo tipo que se realizan simultáneamente. Es decir, las ejecuciones marcadas como group
(tag para agrupar cierto tipo de jobs) se podrían ejecutar al mismo tiempo o ser ejecutadas de a una.
Por defecto, la opción cancel-in-progress
está activada y por esto obtenemos el resultado esperado: Cancelar todas las ejecuciones menos la más reciente.
Si cancel-in-progress
se desactiva, cada uno de las ejecuciones encoladas se pausará y terminarán una a la vez hasta llegar a la más reciente.
De momento es la opción recomendada: Al ejecutarse en la sección de configuración del flujo de trabajo es más rápida y ahorra recursos ya que en este punto aún no se han desplegado los requerimientos de los jobs.
Top comments (0)