Running jobs on larger runners

После определения типа runner вы можете обновить файлы YAML рабочего процесса, чтобы отправить задания только что созданным экземплярам runner для обработки. Группы или метки запуска можно использовать для определения места выполнения заданий.

Только учетные записи владельца или администратора могут просматривать параметры runner. Пользователи, не являющиеся администраторами, могут связаться с владелец организации, чтобы узнать, какие средства запуска включены. Владелец организации могут создавать новые группы запуска и группы runner, а также настраивать разрешения, чтобы указать, какие репозитории могут получить доступ к группе runner. Дополнительные сведения см. в разделе Managing larger runners.

Using groups to control where jobs are run

В этом примере средства запуска 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

Using labels to control where jobs are run

Вы можете неявно передать метку runs-on в ключ с помощью синтаксиса runs-on: LABEL. Кроме того, можно использовать labels ключ, как показано в приведенном ниже примере.

In this example, the runs-on key sends the job to any available runner that has been assigned the ubuntu-20.04-16core label:

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 может узнать метки для выполняющихся, доступных в этом репозитории. См . раздел AUTOTITLE.

Using labels and groups to control where jobs are run

При сочетании групп и меток средство выполнения должно соответствовать обоим требованиям, чтобы иметь право на выполнение задания.

В этом примере вызываемая ubuntu-runners группа runner заполняется средствами запуска Ubuntu, которые также были назначены меткой ubuntu-20.04-16core. Ключ runs-on объединяется group и labels таким образом, чтобы задание перенаправлялось на любой доступный runner в группе, которая также имеет соответствующую метку:

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

Использование уникальных имен для групп runner

Для GitHub Actions требуется, чтобы имена групп runner были уникальными на уровне организации. Это означает, что организация больше не сможет создать группу бегунов с тем же именем, что и в организации. Кроме того, пользователи увидят предупреждающий баннер на всех группах runner, которые используют то же имя, что и группа в организации, предлагая переименовать группу организации.

Чтобы избежать неоднозначности, рабочий процесс завершится ошибкой, если в организации и организации имеются повторяющиеся группы runner. Чтобы устранить эту проблему, можно переименовать одну из групп бегунов в организации или предприятия или обновить файл рабочего процесса, чтобы добавить префикс в имя группы runner:

• org/ или organization/
• ent/ или enterprise/

Пример. Использование префиксов для отличия групп runner

Например, если у вас есть группа runner с именем 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 ]

Если вы заметили, что задания, предназначенные для ваших крупное средство выполненияs, задерживаются или не выполняются, существует несколько факторов, которые могут привести к этому.

• Параметры параллелизма: возможно, достигнуто максимальное ограничение параллелизма. Если вы хотите включить параллельное выполнение дополнительных заданий, можно обновить параметры автомасштабирования до большего числа. Дополнительные сведения см. в разделе Managing larger runners.
• Разрешения репозитория. Убедитесь, что для ваших крупное средство выполненияs включены соответствующие разрешения репозитория. По умолчанию средства выполнения предприятия недоступны на уровне репозитория и должны быть включены администратором организации вручную. Дополнительные сведения см. в разделе Managing larger runners.
• Сведения о выставлении счетов: для использования крупное средство выполненияs должна быть допустимая кредитная карта. После добавления кредитной карты в учетную запись может потребоваться до 10 минут, чтобы включить использование данных крупное средство выполненияs. Дополнительные сведения см. в разделе Управление сведениями об оплате и выставлении счетов.
• Ограничение расходов: для ваших GitHub Actions необходимо задать значение больше нуля. Дополнительные сведения см. в разделе Использование бюджетов для контроля расходов на лимитные продукты.
• Политика справедливого использования: GitHub имеет политику справедливого использования, которая начинает регулировать задания на основе нескольких факторов, таких как количество выполняемых заданий или сколько заданий выполняется в целом GitHub Actions.
• Очередь заданий для назначения времени: очередь заданий для назначения времени ссылается на время между запросом задания и GitHub, назначая виртуальную машину для выполнения задания. Стандартные GitHubразмещенные в среде runner, использующие назначенные метки рабочих процессов YAML (например ubuntu-latest, всегда находятся в состоянии "тепло". С большими бегунами теплый компьютер может не быть готов к выбору задания по первому запросу, так как пулы для этих компьютеров меньше. В результате GitHub может потребоваться создать новую виртуальную машину, которая увеличивает очередь для назначения времени. После использования средства выполнения виртуальные машины легко выполняются для последующих запусков рабочего процесса, уменьшая время назначения очереди для будущего рабочего процесса в течение следующих 24 часов.