Resumen

  • La concurrencia de GitHub Actions controla jobs o runs que comparten una clave de grupo; la cola, sustitución y cancelación dependen de su configuración.
  • GitHub documenta que la concurrencia y el entorno no están conectados automáticamente.
  • Probar serialización exige clave efectiva, miembros y disposición, ejecución y una observación independiente del destino.

«El despliegue está serializado» puede ser una preferencia de agenda y no una observación operativa. GitHub Actions permite declarar un grupo para un workflow o job. Con él puede impedirse la ejecución paralela de trabajo que resuelva a la misma clave, sustituirse un run pendiente o conservarse más espera cuando se configura una cola. Es un control valioso, pero no alcanza a un workflow que no use la clave ni a una acción de destino cuya relación con el grupo no se haya demostrado.

Los estados importan. GitHub explica que normalmente puede existir un miembro en ejecución y uno pendiente, y que una llegada posterior puede sustituir al pendiente anterior. queue: max habilita una fila limitada; cancel-in-progress: true también puede cancelar trabajo que ya corre. Que un run figure como pendiente no muestra que todos los anteriores siguieran esperando. Que esté cancelado no dice si antes emitió una llamada externa, publicó un artefacto o modificó un destino.

El orden tampoco se deduce del momento de despacho. GitHub documenta FIFO desde el momento en que el trabajo comenzó a esperar y advierte que el inicio efectivo puede variar. Una afirmación temporal requiere la expresión y clave expandidas, los runs o jobs que pertenecieron a ella, sus tiempos de espera, inicio y conclusión, y las identidades de fuente y artefacto. Una etiqueta de grupo no llena esos registros.

GitHub separa de forma expresa concurrencia y entorno. El valor de concurrencia puede ser cualquier cadena y otro workflow que use el mismo entorno sin esa clave no queda sujeto a su regla. Las protecciones de entorno pueden operar a la vez, pero no vuelven universal a la clave; la clave tampoco es un bloqueo universal del entorno. Son controles diferentes y deben auditarse como tales.

La API de grupos de concurrencia puede enseñar miembros activos y sus estados. Es evidencia útil sobre lo que GitHub observa en el grupo en ese momento. No reemplaza una comprobación del sistema atendido. Daniel Kade recomienda guardar expresión y expansión, política de cola/cancelación, miembros y tiempos, commit y artefacto, elección de entorno, ejecución y observación objetivo con método y hora. Puede ocultarse información sensible; no debe inventarse una unión entre el planificador y la realidad exterior.

Fuentes

  1. GitHub Docs — Concurrency
  2. GitHub Docs — Workflow syntax
  3. GitHub Docs — Deploying with GitHub Actions
  4. GitHub Docs — Actions concurrency groups REST API