Что делать, если GitHub Actions macOS Runner слишком долго стоит в очереди? Как оценить расширение в 2026 году

Job GitHub Actions остаётся в состоянии Queued, а шаги сборки iOS так и не начинаются.

Быстрое решение: не перезапускайте задачу вслепую и не расширяйте Runner-пул сразу. Сначала выясните, началось ли выполнение; затем проверьте concurrency, маршрутизацию по меткам и доступность self-hosted Runner. Если задержка устойчива и вызвана нехваткой собственной среды, рассмотрите дополнительный Mac Runner как параллельный вариант — он не устранит сбой планировщика GitHub.

Кому пригодится: независимым разработчикам, чьи задачи сборки или публикации iOS стоят в очереди.
Небольшим командам, для которых задержки macOS CI сдвигают слияние изменений или выпуск.
Разработчикам, поддерживающим собственный Runner и проверяющим его состояние, метки и получение заданий.

Последнее обновление: 11 ноября 2026 года. Данные сверены с ограничениями GitHub Actions, документацией по hosted Runner и страницей состояния сервиса.

Сначала определите, где остановился job

Время полного workflow само по себе не показывает, что именно задерживает сборку. Долгий запуск может складываться из ожидания Runner, подготовки окружения, установки зависимостей, компиляции и тестов. Это разные этапы, и для каждого нужна своя проверка.

Откройте конкретный запуск в интерфейсе или через GitHub CLI:

gh run view RUN_ID
gh run view RUN_ID --log

В выводе найдите нужный job и проверьте его состояние, временную шкалу и список шагов. Возможны три существенно разные ситуации:

• Job ещё не получил Runner. Шаги не начинались. Ищите очередь платформы, ограничения concurrency или несовпадение параметров маршрутизации.
• Runner назначен, но инициализация не завершилась. Проверьте журналы Runner и сообщения о запуске процесса. Здесь важно понять, дошло ли задание до машины.
• Шаги выполняются или уже завершились с ошибкой. Это может быть проблема Xcode, зависимостей, подписи или тестов. Увеличение числа Runner не исправит ошибку внутри сборки.

При диагностике сохраните ссылку на запуск, идентификатор job, время возникновения проблемы и сообщение об ошибке. Если job отменён до первого шага, проверьте, была ли отмена ручной или связанной с настройкой workflow. Не считайте любую такую отмену доказательством нехватки macOS Runner.

Состояние GitHub и признаки hosted Runner

Если очередь затрагивает только macOS job на GitHub-hosted macOS Runner, а остальные задачи проекта стартуют, прежде проверьте платформенную сторону. Посмотрите текущий статус компонентов GitHub и сравните его со временем проблемного запуска. Затем сверьтесь с документацией об ограничениях GitHub Actions: доступность параллельных запусков зависит от предусмотренных платформой ограничений и конфигурации аккаунта.

В журнале workflow ищите сообщения о невозможности получить Runner, недоступности ёмкости или отмене задания до начала шагов. Запишите точный текст ошибки: похожие внешне симптомы могут возникать по разным причинам. Повторный запуск имеет смысл после проверки статуса или изменения условий, а не как единственный метод диагностики.

В ограничениях GitHub указано, что срок ожидания job в очереди может достигать 24 часов, после чего задание завершается ошибкой. Там же описано максимальное время выполнения одного job — 6 часов. Это разные ограничения: первое относится к ожиданию назначения, второе — к исполнению уже запущенной задачи. Перед применением этих значений проверьте актуальную редакцию официальной документации по лимитам.

В период с 3 по 9 ноября 2026 года участники GitHub Community сообщали о проблемах с macOS arm64 job: в отдельных случаях появлялись сообщения о ёмкости или задача завершалась до выполнения шагов. Это пользовательские сообщения, а не подтверждение общей неисправности или официального решения. Их можно использовать как повод сверить собственные временные отметки со страницей обсуждения, но нельзя по ним заключать, что тот же инцидент затронул все аккаунты.

Не повторяйте один и тот же запуск многократно, пока не сохранены исходные журналы. Новые попытки меняют время и контекст наблюдения, но не объясняют, на каком этапе остановился первоначальный job.

Self-hosted Runner: состояние, метки и группы

Если workflow направлен на собственный Runner, очередь может означать, что GitHub не нашёл подходящую машину. Она также может означать, что Runner получил задание, но не смог штатно его начать. Сначала выясните, к какому случаю относится запуск.

Проверьте в настройках репозитория или организации, что Runner отображается как онлайн и не занят другим заданием. Затем сравните метки в workflow с метками зарегистрированной машины. Job с требованием macOS, ARM64 или пользовательской меткой не будет направлен на Runner, если нужной метки у него нет. Дополнительно проверьте, доступна ли job та Runner group, в которой находится машина. Правила самих Runner, включая метки и области доступности, описаны в документации self-hosted Runner.

Для первичной проверки списка машин можно использовать API:

gh api repos/OWNER/REPO/actions/runners \
  --jq '.runners[] | {name, status, busy, labels: [.labels[].name]}'

Пример полезного фрагмента вывода:

{
  "name": "ios-builder",
  "status": "online",
  "busy": false,
  "labels": ["self-hosted", "macOS", "ARM64", "ios"]
}

online и busy: false помогают понять состояние машины, но ещё не доказывают, что job может на неё попасть. Сверьте все обязательные метки и правила группы. Если Runner онлайн, но задание остаётся в очереди, проверьте журналы сервиса и время последнего подключения. Если машина приняла job, но запуск остановился при инициализации, исследуйте локальное состояние Runner и процесс выполнения. Для этого GitHub предлагает отдельные рекомендации по мониторингу и устранению проблем self-hosted Runner.

Очередь workflow и ошибочные повторы

Иногда дополнительные машины не нужны: задания задерживаются из-за правил самого проекта. Проверьте блок concurrency, особенно если одинаковая группа используется несколькими workflow. Настройка может оставлять только один актуальный запуск или отменять предыдущий. Для проверки прочитайте конфигурацию и сопоставьте её с временной шкалой в истории запусков. Описание поведения и параметров приведено в руководстве GitHub по управлению параллельностью workflow.

concurrency:
  group: ios-${{ github.ref }}
  cancel-in-progress: true

Такое правило связывает запуски с веткой и допускает отмену предыдущего процесса для той же группы. Для быстрой проверки pull request это может быть намеренным поведением. Для публикации, где требуется дождаться каждого релизного кандидата, оно может привести к нежелательной отмене. Перед изменением убедитесь, что отменённый job не выполнял обязательную проверку или публикационный шаг.

Также посмотрите на матрицу сборок и повторные триггеры. Изменение документации, повторная отправка одного и того же коммита или параллельные проверки могут создавать дополнительные macOS job без дополнительной ценности. Если часть проверок не требует macOS, её можно запускать раньше на подходящей среде, а macOS этап оставить для сборки, тестирования или упаковки приложения. Это уменьшает лишнюю конкуренцию внутри workflow, но не гарантирует решение проблемы ёмкости hosted Runner.

Для поиска причин отмены и ошибок полезно пройти официальный порядок диагностики workflow. Важны не только итоговый статус, но и инициатор отмены, имя concurrency group, связанные запуски и фактический момент назначения Runner.

Выбор действия по симптомам

Сопоставьте наблюдаемое поведение с ближайшей причиной. В таблице «добавить Mac Runner» означает расширить собственную доступную среду, а не заменить работу платформенного планировщика.

Применяйте решения по ветке диагностики:

• Есть подтверждённое сообщение о сбое или ограничении hosted-среды. Сохраните журналы и проверьте официальный статус. Дождитесь обновления либо повторите запуск, когда условия изменятся. Собственный Runner не исправит проблему на стороне сервиса.
• Причина в concurrency или лишних запусках. Измените правило только после проверки того, какие job можно отменять. Сначала проверьте конфигурацию на тестовой ветке.
• Проблема в self-hosted Runner. Восстановите соединение, освободите занятую машину или исправьте метки и группу. Проверьте статус и журналы повторно.
• Mac-среды не хватает при исправном workflow. Оцените дополнительный self-hosted Mac Runner как параллельный исполнитель. Он может принять часть заданий, если GitHub способен их ему назначить и конфигурация позволяет использовать эту машину.
• Ошибка возникла после старта шагов. Изучите конкретный шаг и вывод сборки. Очередь и скорость выполнения нельзя считать одной проблемой.

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

Приёмка альтернативного Mac Runner на iOS-задаче

Проверяйте резервную среду на рабочем workflow, а не только на успешной регистрации Runner. До изменения процесса зафиксируйте исходные данные: коммит, запускаемый workflow, обязательные метки, используемую версию Xcode, целевой тип сборки и ожидаемый результат. Это позволит сравнить поведение на исходном и альтернативном исполнителе.

Практический порядок:

1. Выберите репрезентативную задачу. Возьмите сборку или тест, который действительно задерживал команду. Не начинайте с публикации, использующей production-секреты.
2. Проверьте доступность и маршрутизацию. Подтвердите, что Runner онлайн, не занят и видит все метки, заданные в workflow. Убедитесь, что для job разрешена его Runner group.
3. Проверьте выбранный Xcode. В журнале CI зафиксируйте версию инструментов и доступную схему проекта. Успешный старт не означает, что среда выбрала требуемый toolchain.
4. Запустите сборку или тест. Сохраните лог от момента назначения job до завершения последнего шага. Отметьте отдельно ожидание Runner, подготовку окружения и собственно работу проекта.
5. Проверьте результат. Убедитесь, что создан ожидаемый продукт сборки или архив, тесты завершились с ожидаемым статусом, а подпись не использовала неподходящие ключи. Для публикационного процесса проверяйте передачу артефакта отдельно от компиляции.
6. Повторите проверку в условиях команды. Проверьте, как Runner ведёт себя при обычном параллельном workflow, и как восстанавливается после остановки службы или перезапуска машины. Не делайте вывод о надёжности по одному успешному запуску.

При оценке удалённого Mac заранее изучите, как устроены варианты аренды Mac и расчёт расходов. До переноса постоянной задачи сначала проверьте фактическое подключение Runner, доступность нужных инструментов и результат собственного workflow. Не предполагайте заранее, что любая удалённая машина автоматически подходит для вашего процесса.

Частые вопросы

Job долго остаётся в Queued

Сначала проверьте, назначен ли Runner и начались ли шаги. Если шагов нет, исследуйте статус GitHub, ограничения и параметры маршрутизации. Для self-hosted Runner отдельно проверьте состояние машины, занятость, метки и группу.

Job отменяется до первого шага

Сохраните временную шкалу и сообщение об отмене. Проверьте, не действует ли concurrency, не отменён ли запуск вручную и был ли Runner назначен. Сообщение о ёмкости — повод свериться со статусом сервиса, но не доказательство массового сбоя.

Очередь может возникнуть из-за concurrency

Да. Сопоставьте отменённые и ожидающие запуски, их concurrency group и значение cancel-in-progress. Если задержка возникает только в одной группе, сначала проверяйте правила workflow, а не добавляйте Mac.

Self-hosted Mac Runner помогает при очереди iOS-сборки

Он может добавить независимую среду выполнения для задач, если проект умеет направлять их на эту машину. Он не исправляет GitHub scheduler и не заменяет диагностику сервиса. Перед решением проверьте реальный iOS workflow, версию Xcode и артефакт сборки.

Если задержки вызваны не неисправным workflow, а нехваткой постоянно доступной Mac-среды, hosted Runner оставляет команде несколько ограничений: параллельность зависит от платформенных лимитов, состояние выделенного исполнителя нельзя полностью контролировать, а сборочную задачу приходится планировать в рамках доступных правил сервиса. В таком случае аренда удалённого Mac у SFTPMAC может дать команде отдельную среду для проверки и выполнения iOS-задач, но её пригодность следует подтвердить собственным workflow. Сравните варианты удалённого Mac, подключите тестовую задачу и принимайте решение по фактическому результату.