Ejecución de trabajos en ejecutores más grandes

Uso de grupos para controlar dónde se ejecutan los trabajos

En este ejemplo, se han agregado ejecutores de Ubuntu a un grupo denominado ubuntu-runners. La clave runs-on envía el trabajo a cualquier ejecutor disponible del grupo ubuntu-runners:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: 
      group: ubuntu-runners
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Uso de etiquetas para controlar dónde se ejecutan los trabajos

En este ejemplo, la clave runs-on envía el trabajo a cualquier ejecutor disponible asignado a la etiqueta ubuntu-24.04-16core:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on:
      labels: ubuntu-24.04-16core
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Cualquier persona con acceso de escritura a un repositorio habilitado para Acciones puede averiguar las etiquetas de los ejecutores que están disponibles en ese repositorio. Consulta Ejecución de trabajos en ejecutores más grandes.

Uso de etiquetas y grupos para controlar dónde se ejecutan los trabajos

Al combinar grupos y etiquetas, el ejecutor debe cumplir ambos requisitos para poder ejecutar el trabajo.

En este ejemplo, un grupo de ejecutores denominado ubuntu-runners se rellena con ejecutores de Ubuntu, a los que también se ha asignado la etiqueta ubuntu-24.04-16core. La clave runs-on combina group y labels para que el trabajo se enrute a cualquier ejecutor disponible dentro del grupo que también tenga una etiqueta coincidente:

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on:
      group: ubuntu-runners
      labels: ubuntu-24.04-16core
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Uso de nombres únicos para grupos de ejecutores

GitHub Actions requiere que los nombres del grupo de ejecutores sean únicos a nivel de organización. Esto significa que una organización ya no podrá crear un grupo de ejecutores con el mismo nombre que uno de la empresa. Además, los usuarios verán un banner de advertencia en cualquier grupo de ejecutores que comparta el mismo nombre que un grupo de la empresa, que sugiere que se debe cambiar el nombre del grupo de la organización.

Para evitar ambigüedad, se producirá un error en un flujo de trabajo si hay grupos de ejecutores duplicados en la organización y en la empresa. Para solucionarlo, puedes cambiar el nombre de uno de los grupos de ejecutores de la organización o de la empresa, o bien actualizar el archivo de flujo de trabajo para agregar un prefijo al nombre del grupo de ejecutores:

• org/ o organization/
• ent/ o enterprise/

Ejemplo: Uso de prefijos para diferenciar grupos de ejecutores

Por ejemplo, si tienes un grupo de ejecutores denominado my-group en la organización y otro denominado my-group en la empresa, puedes actualizar el archivo de flujo de trabajo para usar org/my-group o ent/my-group para diferenciar entre los dos.

Usar org/:

runs-on:
  group: org/my-group
  labels: [ self-hosted, label-1 ]

Usar ent/:

runs-on:
  group: ent/my-group
  labels: [ self-hosted, label-1 ]

Si observas que los trabajos que se dirigen a tus ejecutor más grandes se retrasan o no se ejecutan, las causas pueden ser varias.

• Configuración de simultaneidad: es posible que hayas alcanzado el límite máximo de simultaneidad. Si quieres permitir que más trabajos se ejecuten en paralelo, puedes actualizar la configuración de escalado automático a un número mayor. Para más información, consulta Administración de ejecutores más grandes.
• Permisos de repositorio: asegúrate de tener habilitados los permisos de repositorio adecuados para los ejecutor más grandes. De forma predeterminada, los ejecutores de empresa no están disponibles a nivel de repositorio y un administrador de la organización debe habilitarlos manualmente. Para más información, consulta Administración de ejecutores más grandes.
• Información de facturación: debes tener una tarjeta de crédito válida en el archivo para poder usar ejecutor más grandes. Después de agregar una tarjeta de crédito a tu cuenta, puede tardar hasta 10 minutos en permitirse el uso de los ejecutor más grandes. Para más información, consulta Administración de la información de facturación y pago.
• Límite de gasto: el límite de gasto de GitHub Actions debe establecerse en un valor mayor que cero. Para más información, consulta Configuración de presupuestos para controlar el gasto en productos medidos.
• Directiva de uso justo: GitHub tiene una directiva de uso justo que comienza a limitar los trabajos en función de varios factores, como el número de trabajos que se ejecutan o cuántos trabajos se ejecutan en la totalidad de GitHub Actions.
• Cola de trabajos para asignar tiempo: la cola de trabajos para asignar tiempo hace referencia al tiempo entre una solicitud de trabajo y GitHub asignando una máquina virtual para ejecutar el trabajo. Los ejecutores hospedados estándar GitHub que usan etiquetas de flujo de trabajo YAML prescritas (como ubuntu-latest) siempre están en un estado “activo”. Con los ejecutores de mayor capacidad, es posible que una máquina virtual activa no esté lista para aceptar un trabajo en la primera solicitud, ya que los grupos de estas máquinas son más pequeños. Como resultado, es posible que GitHub tenga que crear una nueva máquina virtual, lo que aumenta la cola para asignar tiempo. Una vez que un ejecutor está en uso, las máquinas virtuales están listas para las ejecuciones de flujo de trabajo posteriores en cinco minutos. Si no se vuelven a usar durante ese tiempo, un subconjunto de esas máquinas permanecen semiactivas, lo que reduce la cola para asignar tiempo a futuras ejecuciones de flujo de trabajo en las 24 horas siguientes. Cuanto mayor sea el volumen de trabajos que ejecutes, más máquinas virtuales permanecerán en el grupo intermedio.