DEV Community 👩‍💻👨‍💻

Alejandro E. Rendon
Alejandro E. Rendon

Posted on

Concurrencia en flujos de Github Actions

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:

ejemplo-multiples-ejecuciones-mismo-job

on:
  push:
    branches:
    - staging # Despliegue de aplicación
  pull_request:
    branches:
    - staging # Validaciones por cada commit agregado en un Pull Request
Enter fullscreen mode Exit fullscreen mode

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.

  1. 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 }}
      ...
Enter fullscreen mode Exit fullscreen mode

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.

  1. 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
Enter fullscreen mode Exit fullscreen mode

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.

ejemplo-multiples-ejecuciones-mismo-job-cancelar

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.

ejemplo-multiples-ejecuciones-mismo-job-cola

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)

Let's Get Wacky


Use any Linode offering to create something unique or silly in the DEV x Linode Hackathon 2022 and win the Wacky Wildcard category

Join the Hackathon <-