在较大的运行器上运行作业

定义了运行器类型后，可以更新工作流 YAML 文件，以将作业发送到新创建的运行器实例进行处理。 可使用运行器组或标签来定义作业的运行位置。

只有所有者或管理员帐户可查看运行器设置。 非管理用户可联系组织所有者，了解启用了哪些运行器。 组织所有者可创建新的运行器和运行器组，并配置权限来指定哪些存储库可访问运行器组。 有关详细信息，请参阅“管理较大的运行器”。

使用组来控制作业的运行位置

在此示例中，Ubuntu 运行器已添加到名为 ubuntu-runners 的组中。 runs-on 键将作业发送到 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

使用标签来控制作业的运行位置

可以使用语法 runs-on: LABEL 隐式地将标签传递给 runs-on 键。 或者，可以使用 labels 键，如下例所示。

在此示例中， runs-on 密钥将作业发送给已分配 ubuntu-20.04-16core 标签的任何可用运行器：

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on:
      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

对启用了 Actions 的存储库具有写权限的任何人都可以找到该存储库中可用的运行器的标签。 请参阅“在较大的运行器上运行作业”。

使用组和组来控制作业的运行位置

组合组和标签时，运行器必须满足这两项要求才能运行作业。

在此示例中，名为 ubuntu-runners 的运行器组使用 Ubuntu 运行器（分配了标签 ubuntu-20.04-16core）进行填充。 runs-on 键将 group 和 labels 组合在一起，以便将作业路由到具有匹配标签的组内的任何可用运行器：

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

对运行器组使用唯一名称

GitHub Actions 要求运行器组名称在组织级别必须唯一。 这意味着组织将无法再创建与企业中的运行器组同名的运行器组。 此外，用户将在与企业中的组共享相同名称的任何运行器组上看到警告横幅，建议重命名组织组。

为了避免混淆，如果组织和企业中存在重复的运行器组，工作流将失败。 若要解决此问题，可以重命名组织或企业中的某个运行器组，也可以更新工作流文件以向运行器组名称添加前缀：

• org/ 或 organization/
• ent/ 或 enterprise/

示例：使用前缀区分运行器组

例如，如果组织中有一个名为 my-group 的运行器组，企业中有另一个名为 my-group 的运行器组，则可以更新工作流文件以使用 org/my-group 或 ent/my-group 来区分这两者。

使用 org/：

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

使用 ent/：

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

如果你注意到面向 大型运行器 的作业延迟或未运行，则有几个因素可能导致此问题。

• 并发设置：可能已达到最大并发限制。 如果想要允许更多作业并行运行，可以将自动缩放设置更新为更大的数字。 有关详细信息，请参阅“管理较大的运行器”。
• 存储库权限：确保为 大型运行器 启用适当的存储库权限。 默认情况下，企业运行器在存储库级别不可用，必须由组织管理员手动启用。 有关详细信息，请参阅“管理较大的运行器”。
• 计费信息：必须在文件中具有有效的信用卡卡才能使用 大型运行器。 将信用卡添加到帐户后，可能需要 10 分钟才能使用 大型运行器。 有关详细信息，请参阅“添加或编辑付款方式”。
• 支出限制：GitHub Actions 支出限制必须设置为大于零的值。 有关详细信息，请参阅“管理 GitHub Actions 的支出限制”。
• 公平使用策略：GitHub 有一个公平使用策略，该策略根据多个因素开始限制作业，例如正在运行的作业数或在整个 GitHub Actions 中运行的作业数。
• 作业排队到分配间隔时间：作业排队到分配间隔时间是指从发出作业请求到 GitHub 分配虚拟机来执行该作业之间的间隔时间。 使用规定 YAML 工作流标签（如 ubuntu-latest）的标准 GitHub 托管运行器始终处于“暖”状态。 对于大型运行器，由于这些计算机池较小，一台暖机可能无法做好在第一次收到请求时选取作业的准备。 因此，GitHub 可能需要创建新的虚拟机，这会增加从排队到分配的间隔时间。 运行器开始使用后，虚拟机随时可用于后续工作流运行，从而减少接下来 24 小时内的未来工作流运行的从排队到分配的间隔时间。