Using self-hosted runners in a workflow

You can target self-hosted runners for use in a workflow based on the labels assigned to the runners, or their group membership, or a combination of these.

About self-hosted runner labels

Labels allow you to send workflow jobs to specific types of self-hosted runners, based on their shared characteristics. For example, if your job requires a particular hardware component or software package, you can assign a custom label to a runner and then configure your job to only execute on runners with that label.

A fin de especificar un ejecutor autohospedado para el trabajo, configure runs-on en el archivo de flujo de trabajo con las etiquetas de ejecutor autohospedado.

Los ejecutores autohospedados pueden tener la etiqueta self-hosted. Al configurar un ejecutor autohospedado, de forma predeterminada se incluirá la etiqueta self-hosted. Puedes pasar la marca --no-default-labels para evitar que se aplique la etiqueta autohospedada. Las etiquetas pueden usarse para crear opciones de destino para los ejecutores, como el sistema operativo o la arquitectura, se recomienda proporcionar una serie de etiquetas que comience con self-hosted (debe estar en primer lugar) y que luego incluya etiquetas adicionales según sea necesario. Cuando especifiques un arreglo de etiquetas, los jobs se pondrán en cola cuando se trate de ejecutores que tengan todas las etiquetas que especificas.

Hay que tener en cuenta que action-runner-controller no admite varias etiquetas y no admite la etiqueta self-hosted.

For information on creating custom and default labels, see Using labels with self-hosted runners.

About self-hosted runner groups

For self-hosted runners defined at the organization or enterprise levels, you can group your runners with shared characteristics into a single runner group and then configure your job to target the runner group.

To specify a self-hosted runner group for your job, configure runs-on.group in your workflow file.

For information on creating and managing runner groups, see Managing access to self-hosted runners using groups.

Viewing available runners for a repository

Si tienes acceso repo: write a un repositorio, puedes ver una lista de los ejecutores disponibles para el repositorio.

1. En GitHub, navegue hasta la página principal del repositorio.

2. En el nombre del repositorio, haz clic en Acciones.

   

3. En la barra lateral izquierda, en la sección "Administración", haz clic en Ejecutores.

4. Click the Self hosted tab at the top of the list of runners.

5. Review the list of available self-hosted runners for the repository. This list includes both self-hosted runners and runner scale sets created with Actions Runner Controller. For more information, see About Actions Runner Controller.

6. Opcionalmente, para copiar la etiqueta de un ejecutor para usarla en un flujo de trabajo, haz clic en a la derecha del ejecutor y, a continuación, haz clic en Copiar etiqueta.

Using default labels to route jobs

A self-hosted runner automatically receives certain labels when it is added to GitHub Actions. These are used to indicate its operating system and hardware platform:

• self-hosted: Default label applied to self-hosted runners.
• linux, windows, or macOS: Applied depending on operating system.
• x64, ARM, or ARM64: Applied depending on hardware architecture.

You can use your workflow's YAML to send jobs to a combination of these labels. In this example, a self-hosted runner that matches all three labels will be eligible to run the job:

runs-on: [self-hosted, linux, ARM64]

• self-hosted - Run this job on a self-hosted runner.
• linux - Only use a Linux-based runner.
• ARM64 - Only use a runner based on ARM64 hardware.

To create individual self-hosted runners without the default labels, pass the --no-default-labels flag when you create the runner. Actions Runner Controller does not support multiple labels.

Using custom labels to route jobs

You can create custom labels and assign them to your self-hosted runners at any time. Custom labels let you send jobs to particular types of self-hosted runners, based on how they're labeled.

For example, if you have a job that requires a specific type of graphics hardware, you can create a custom label called gpu and assign it to the runners that have the hardware installed. A self-hosted runner that matches all the assigned labels will then be eligible to run the job.

This example shows a job that combines default and custom labels:

runs-on: [self-hosted, linux, x64, gpu]

• self-hosted - Run this job on a self-hosted runner.
• linux - Only use a Linux-based runner.
• x64 - Only use a runner based on x64 hardware.
• gpu - This custom label has been manually assigned to self-hosted runners with the GPU hardware installed.

These labels operate cumulatively, so a self-hosted runner must have all four labels to be eligible to process the job.

Using groups to route jobs

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@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Using labels and groups to route jobs

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-20.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-20.04-16core
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Routing precedence for self-hosted runners

When routing a job to a self-hosted runner, GitHub looks for a runner that matches the job's runs-on labels and groups:

• If GitHub finds an online and idle runner that matches the job's runs-on labels and groups, the job is then assigned and sent to the runner.
  • If the runner doesn't pick up the assigned job within 60 seconds, the job is re-queued so that a new runner can accept it.
• If GitHub doesn't find an online and idle runner that matches the job's runs-on labels and groups, then the job will remain queued until a runner comes online.
• If the job remains queued for more than 24 hours, the job will fail.

Workflow run continuity

Si los servicios de las GitHub Actions se encuentran temporalmente no disponibles, entonces se descartará una ejecución de flujo de trabajo si no se puso en cola en los primeros 30 minutos después de activarse. Por ejemplo, si un flujo de trabajo se activa y los servicios de las GitHub Actions no están disponibles por 31 minutos o más, entonces la ejecución de flujo de trabajo no se procesará.