# Control de la simultaneidad de flujos de trabajo y tareas Administra qué flujos de trabajo y trabajos se pueden ejecutar simultáneamente. ## Uso de la simultaneidad en diferentes escenarios Use `jobs..concurrency` para asegurarse de que solo se ejecute al mismo tiempo un trabajo o flujo de trabajo que use el mismo grupo de concurrencia. Un grupo de concurrencia puede ser cualquier secuencia o expresión. Contextos de expresión permitidos: [`github`](/es/actions/reference/workflows-and-actions/contexts#github-context), [`inputs`](/es/actions/reference/workflows-and-actions/contexts#inputs-context), [`vars`](/es/actions/reference/workflows-and-actions/contexts#vars-context), [`needs`](/es/actions/reference/workflows-and-actions/contexts#needs-context), [`strategy`](/es/actions/reference/workflows-and-actions/contexts#strategy-context) y [`matrix`](/es/actions/reference/workflows-and-actions/contexts#matrix-context). Para más información sobre las expresiones, consulta [Evaluación de expresiones en flujos de trabajo y acciones](/es/actions/reference/workflows-and-actions/expressions). También puede especificar `concurrency` en el nivel de flujo de trabajo. Para más información, vea [`concurrency`](/es/actions/reference/workflows-and-actions/workflow-syntax#concurrency). Esto significa que en cualquier momento puede haber como máximo un trabajo o flujo de trabajo en ejecución en un grupo de concurrencia. Cuando un trabajo o flujo de trabajo concurrente se pone en cola, si otro trabajo o flujo de trabajo que utilicen el mismo grupo de simultaneidad en el repositorio se encuentra en curso, el trabajo o flujo de trabajo en cola se mostrará como `pending`. De forma predeterminada, cualquier trabajo o flujo de trabajo `pending` existente en el mismo grupo de simultaneidad se cancelará y el nuevo trabajo o flujo de trabajo en cola ocupará su lugar. Para cancelar también cualquier trabajo o flujo de trabajo actualmente en ejecución en el mismo grupo de simultaneidad, especifica `cancel-in-progress: true`. Para cancelar condicionalmente los trabajos o flujos de trabajo en ejecución actualmente en el mismo grupo de simultaneidad, puede especificar `cancel-in-progress` como una expresión con cualquiera de los contextos de expresión permitidos. Para permitir que más de un `pending` trabajo o ejecución de flujo de trabajo esperen en el mismo grupo de simultaneidad, use la propiedad opcional `queue`. La `queue` propiedad acepta los siguientes valores: * `single` (valor predeterminado): Como máximo, una tarea o ejecución de flujo de trabajo puede estar `pending` en el grupo de concurrencia. Cuando se pone en cola un nuevo trabajo o ejecución de flujo de trabajo, se cancela y reemplaza cualquier trabajo o flujo de trabajo existente `pending` que se ejecute en el mismo grupo. * `max`: hasta 100 trabajos o tareas de flujo de trabajo pueden incluirse en el grupo de concurrencia. Cuando la cola está llena, se cancelan los trabajos o ejecuciones de flujo de trabajo adicionales. La combinación de `queue: max` y `cancel-in-progress: true` no está permitida y producirá un error de validación de flujo de trabajo. > \[!NOTE] > > * El nombre de grupo de simultaneidad no distingue mayúsculas de minúsculas. Por ejemplo, `prod` y `Prod` se tratarán como el mismo grupo de simultaneidad. > * Los trabajos o ejecuciones de flujo de trabajo en el mismo grupo de concurrencia se procesan en el orden primero en entrar, primero en salir (FIFO) según el momento en que cada uno comenzó a esperar en el grupo de concurrencia, no en el momento en que se envió cada flujo de trabajo. Dado que la hora de inicio real de un trabajo o ejecución puede variar, no se garantiza la ordenación. ### Ejemplos: Utilizar la simultaneidad y el comportamiento predeterminado El comportamiento predeterminado de GitHub Actions es permitir que varios trabajos o ejecuciones de flujos de trabajo se ejecuten al mismo tiempo. La `concurrency` palabra clave permite controlar la simultaneidad de las ejecuciones de flujo de trabajo. Por ejemplo, puedes usar la `concurrency` palabra clave inmediatamente después de donde se definen las condiciones del gatillo para limitar la simultaneidad de ejecuciones de flujo de trabajo completas para una rama específica: ```yaml on: push: branches: - main concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` También puede limitar la simultaneidad de los trabajos dentro de un flujo de trabajo usando la `concurrency` palabra clave en el nivel de trabajo: ```yaml on: push: branches: - main jobs: job-1: runs-on: ubuntu-latest concurrency: group: example-group cancel-in-progress: true ``` ### Ejemplo: Grupos de concurrencia Los grupos de simultaneidad proporcionan un método para administrar y limitar las ejecuciones de flujos de trabajo o trabajos que comparten la misma clave de simultaneidad. La `concurrency` tecla se usa para agrupar flujos de trabajo o trabajos en un grupo de concurrencia. Al definir una `concurrency` clave, GitHub Actions garantiza que solo se ejecute un flujo de trabajo o trabajo con esa clave en un momento dado. Si una nueva ejecución de flujo de trabajo o trabajo comienza con la misma `concurrency` clave, GitHub Actions cancelará cualquier flujo de trabajo o trabajo que ya se ejecute con esa clave. La `concurrency` clave puede ser una cadena codificada de forma rígida o puede ser una expresión dinámica que incluya variables de contexto. Es posible definir condiciones de simultaneidad en el flujo de trabajo para que el flujo de trabajo o el trabajo formen parte de un grupo de simultaneidad. Esto significa que cuando se inicia una ejecución o un trabajo, GitHub cancelará las ejecuciones o trabajos que ya estén en curso en el mismo grupo de concurrencia. Esto resulta útil en escenarios en los que desea evitar ejecuciones paralelas para un determinado conjunto de flujos de trabajo o trabajos, como los que se usan para las implementaciones en un entorno de ensayo, con el fin de evitar acciones que puedan provocar conflictos o consumir más recursos de los necesarios. En este ejemplo, `job-1` forma parte de un grupo de simultaneidad denominado `staging_environment`. Esto significa que si se desencadena una nueva ejecución de `job-1`, se cancelarán las ejecuciones del mismo trabajo en el grupo de simultaneidad `staging_environment` que ya están en curso. ```yaml jobs: job-1: runs-on: ubuntu-latest concurrency: group: staging_environment cancel-in-progress: true ``` Alternativamente, el uso de una expresión dinámica como `concurrency: ci-${{ github.ref }}` en el flujo de trabajo significa que el flujo de trabajo o el trabajo formarían parte de un grupo de simultaneidad denominado `ci-` seguido de la referencia de la rama o etiqueta que desencadenó el flujo de trabajo. En este ejemplo, si se inserta un nuevo compromiso en la rama principal mientras una ejecución anterior sigue en curso, se cancelará la ejecución anterior y se iniciará la nueva: ```yaml on: push: branches: - main concurrency: group: ci-${{ github.ref }} cancel-in-progress: true ``` ### Ejemplo: Poner en cola varias ejecuciones pendientes De forma predeterminada, solo un trabajo o ejecución de flujo de trabajo puede estar `pending` en un grupo de concurrencia a la vez. Para permitir que varias ejecuciones se pongan en cola en lugar de cancelarse, establezca `queue: max`. Con `queue: max`, hasta 100 trabajos o ejecuciones de flujo de trabajo pueden esperar en el grupo de simultaneidad; cuando la cola está llena, se cancelan las ejecuciones adicionales. Por ejemplo, el siguiente flujo de trabajo encola las implementaciones en el entorno `production`, procesándolas una a una en orden, según el momento en que cada ejecución comenzó a esperar en el grupo de concurrencia. ```yaml on: push: branches: - main concurrency: group: production-deploy queue: max ``` Tenga en cuenta que `queue: max` no se puede combinar con `cancel-in-progress: true`, porque las dos opciones describen comportamientos conflictivos para manejar las ejecuciones en curso. ### Ejemplo: Utilizar la concurrencia para cancelar cualquier tarea o ejecución en curso Para usar la concurrencia para cancelar cualquier trabajo en curso o ejecución en GitHub Actions, puede usar la clave `concurrency` con la opción `cancel-in-progress` establecida en `true`. ```yaml concurrency: group: ${{ github.ref }} cancel-in-progress: true ``` Tenga en cuenta que en este ejemplo, sin definir un grupo de simultaneidad determinado, GitHub Actions cancelará *cualquier* ejecución en curso del trabajo o flujo de trabajo. ### Ejemplo: Utilizar un valor de respaldo Si compilas el nombre de grupo con una propiedad que solo se defina para eventos específicos, puedes utilizar un valor de segunda opción. Por ejemplo, `github.head_ref` solo se define en eventos `pull_request`. Si tu flujo de trabajo responde a otros eventos además de los eventos `pull_request`, necesitarás proporcionar una segunda opción para evitar un error de sintaxis. El siguiente grupo de simultaneidad cancela los trabajos en curso o solo se ejecuta en eventos `pull_request`; si `github.head_ref` no está definido, el grupo de simultaneidad revertirá al identificador de ejecución, que se garantiza que es único y definido para la ejecución. ```yaml concurrency: group: ${{ github.head_ref || github.run_id }} cancel-in-progress: true ``` ### Ejemplo: Cancelar únicamente las tareas o ejecuciones en curso para el flujo de trabajo actual Si tienes múltiples flujos de trabajo en el mismo repositorio, los nombres de los grupos de concurrencia deben ser únicos en todos los flujos de trabajo para evitar que se cancelen tareas o ejecuciones en progreso de otros flujos de trabajo. De lo contrario, cualquier tarea pendiente o previamente en curso se cancelará, sin importar el flujo de trabajo. Para cancelar solo las ejecuciones en curso del mismo flujo de trabajo, puedes usar la propiedad `github.workflow` para compilar el grupo de simultaneidad: ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` ### Ejemplo: Cancelar solo trabajos en curso en ramas específicas Si desea cancelar trabajos en curso en determinadas ramas, pero no en otras, puede usar expresiones condicionales con `cancel-in-progress`. Por ejemplo, puede hacerlo si desea cancelar trabajos en curso en ramas de desarrollo, pero no en ramas de lanzamiento. Para cancelar solo las ejecuciones en curso del mismo flujo de trabajo cuando no se ejecutan en una rama de versión, puede establecer en `cancel-in-progress` una expresión similar a la siguiente: ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: ${{ !contains(github.ref, 'release/')}} ``` En este ejemplo, hacer múltiples push en una rama `release/1.2.3` no cancelaría las ejecuciones en curso. Las inserciones a otra rama, como `main`, cancelarían las ejecuciones en curso. ## Supervisar tus trabajos actuales en tu organización Para identificar las restricciones con simultaneidad o puesta en cola, puede comprobar cuántos trabajos se están procesando actualmente en los GitHubejecutores hospedados en su organización o empresa. Para más información, consulta [Visualización de los trabajos actuales](/es/actions/how-tos/manage-runners/github-hosted-runners/view-current-jobs).