Что делать при очереди GitHub Actions macOS Runner? Приёмочный список self-hosted Runner на 2026 год

В GitHub Actions, если в runs-on перечислено несколько меток, Runner должен соответствовать им всем — это правило маршрутизации описано в документации по выбору Runner в рабочем процессе. Поэтому не начинайте с покупки или аренды дополнительной машины: сначала проверьте метки, доступ репозитория, состояние Runner и требования задания. Переходите на self-hosted macOS Runner, только если причина действительно в доступной вам мощности или необходимости поддерживать фиксированную среду. А готовность подтверждайте реальным рабочим процессом: задание должно назначаться, собираться, очищаться и восстанавливаться после сбоя.

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

Почему очередь GitHub Actions macOS Runner не всегда означает нехватку машин

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

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

Эта таблица нужна для первичной сортировки, а не для постановки диагноза по одному признаку. У одного и того же сообщения в интерфейсе могут быть разные причины. Проверяйте фактический ход конкретного запуска.

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

Почему онлайн Runner не получает задание

Метки не совпали или рабочему процессу недоступна группа

Откройте YAML-файл рабочего процесса и найдите runs-on. Затем сравните его с метками выбранного Runner. Проверьте каждую метку, включая регистр и написание. Если указаны несколько требований, узел должен соответствовать им всем. В документации GitHub разобраны метки для маршрутизации self-hosted Runner и правила выбора подходящего узла.

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

Для быстрой проверки используйте временный минимальный рабочий процесс. Укажите только одну существующую метку, допустимую для тестового репозитория. Запустите без сборки проекта и без секретов. Если такое задание не назначается, выясняйте маршрутизацию и права. Не добавляйте новые машины, пока этот тест не проходит: дополнительный Runner с теми же ошибочными метками не исправит конфигурацию.

Как понять, почему GitHub Actions Runner всё ещё ждёт

Проверьте последовательно:

• Какую точную строку или массив значений содержит runs-on?
• Какие метки отображаются у Runner сейчас, а не только в документации команды?
• Совпадает ли область регистрации Runner с областью, из которой запускается рабочий процесс?
• Разрешён ли доступ нужному репозиторию через настройки группы?
• Начинает ли тестовое задание выполнять шаги или остаётся без назначения?

Если Runner онлайн, но рабочий процесс не запускается, первым делом проверьте именно маршрут задания и доступ, а затем — регистрацию и состояние службы. Состояние «онлайн» сообщает о доступности Runner, но не подтверждает успешное назначение конкретному заданию. Для наблюдения за состоянием и разбора типичных неисправностей используйте официальное руководство GitHub по мониторингу и устранению неполадок Runner.

Что меняется при выборе GitHub-hosted или собственного macOS Runner

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

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

До миграции проверьте платформенные требования. GitHub публикует поддерживаемые платформы и требования к self-hosted Runner. Для сборок Xcode отдельно учитывайте требования к версии Xcode и macOS: их следует сверять с актуальной таблицей системных требований Apple для Xcode. Не переносите настройку с одного поколения среды на другое по памяти: совместимость инструментария должна быть проверена на целевой машине.

Первый этап: отделите сбой Runner от ошибки сборки

Когда задание начало выполнять шаги, разбор очереди заканчивается. Теперь сравните журнал первого проблемного шага с успешным запуском того же проекта. Запишите версию Xcode, используемые инструменты, способ установки зависимостей и контекст запуска. Различайте отсутствие команды, несовместимость инструмента, сетевую ошибку загрузки пакета и отказ подписи. Каждая из этих причин требует своего исправления.

Для Xcode-проекта проверьте, что установленная версия соответствует требованиям проекта и поддерживается выбранной версией macOS. Затем проверьте доступность хранилищ зависимостей и сетевых ресурсов из Runner. Если сбой возникает при подписи, изучите настройки сертификатов и профилей, срок их действия и способ передачи в рабочий процесс. Не расширяйте права доступа к секретам только потому, что сборка остановилась: сначала определите, на каком именно шаге и по какой причине секрет недоступен.

Удобно фиксировать для каждого сбоя три вещи: шаг, последнее успешное действие и текст ошибки. Например, «зависимость не установилась» — это ещё не доказательство нехватки памяти или вычислительных ресурсов. Если шаг запускается и завершается ошибкой, добавление Runner без изменения сборки не устранит причину. Отдельная запись о маршрутизации помогает не смешивать два класса неисправностей в одном инциденте.

Второй этап: проверьте сеть, службу и восстановление после перезапуска

Оцените не только текущее состояние Runner, но и то, как он ведёт себя после потери связи или перезапуска. Уточните, запускается ли служба автоматически, может ли она повторно связаться с GitHub и кто получает уведомление, если узел перестал принимать задания. Ориентируйтесь на поддерживаемые платформы и инструкции GitHub, а не на предположение, что любое устройство с macOS будет работать как постоянный Runner.

Проведите проверку в контролируемом окне. Сначала выполните тестовое задание и сохраните результат. Затем перезапустите узел и дождитесь, пока Runner вернётся в ожидаемое состояние. После этого отправьте ещё одно безвредное тестовое задание и убедитесь, что оно действительно назначено и завершено. Отдельно проверьте сетевое восстановление, если ваша инфраструктура допускает временный разрыв соединения. Не оставляйте узел просто «включённым» после проверки: подтвердите работу процесса Runner и возможность принять новое задание.

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

Третий этап: подтвердите очистку каталогов и защиту секретов

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

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

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

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

Приёмка перед переводом сборок на self-hosted macOS Runner

Передайте команде не отметку «Runner создан», а результаты испытаний. Используйте контрольный список ниже и приложите к каждому пункту журнал или наблюдаемый результат.

• [ ] Назначение: временный рабочий процесс с требуемыми метками получает именно этот Runner и начинает выполнять шаги.
• [ ] Доступ: проверено, что нужный репозиторий вправе использовать Runner или его группу; ограничения доступа задокументированы.
• [ ] Сборка: минимальная сборка проекта проходит на выбранной среде, а версия Xcode соответствует требованиям проекта.
• [ ] Ошибка: намеренно вызванный безопасный сбой появляется в журнале и не смешивается с проблемой назначения Runner.
• [ ] Оповещение: команда получает сигнал, если узел недоступен или не восстанавливается, и понимает, кто разбирает инцидент.
• [ ] Перезапуск: после перезапуска служба Runner возвращается в рабочее состояние, а новое тестовое задание действительно выполняется.
• [ ] Очистка: после успеха, отмены и ошибки проверены рабочий каталог, временные данные и доступность секретов.
• [ ] Кэш: подтверждено, какие данные сохраняются для ускорения сборок и почему они не раскрывают файлы или сведения между доверительными зонами.

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

Принимать ли собственный Runner: условия выбора

• Если тестовое задание не назначается из-за меток или разрешений, сначала исправьте runs-on, регистрацию и права группы. Дополнительная машина не устранит ошибку правил.
• Если Runner получает задание, но сборка падает на инструменте, зависимости или подписи, сначала исправьте среду и конфигурацию проекта. Не увеличивайте пул узлов без подтверждения дефицита ресурсов.
• Если причиной стали недоступность узла или нехватка управляемой мощности, а у команды есть ответственный за обновление, мониторинг и восстановление, оцените собственный macOS Runner и проведите приёмку по списку выше.
• Если вы не можете гарантировать очистку секретов, разграничение рабочих процессов или восстановление после сбоя, не переносите на Runner чувствительные и критичные задания, пока эти условия не будут обеспечены.
• Если для непрерывной тяжёлой нагрузки важны предсказуемые эксплуатационные расходы, стабильный доступ к физическим интерфейсам или полный контроль машины, сравните аренду с собственной инфраструктурой: временное решение может оказаться неподходящим постоянным основанием для такого процесса.

Перед миграцией полезно оформить требования к среде и удалённому доступу в виде отдельной инструкции. Если при проверке возник вопрос о порядке эксплуатации, можно свериться с разделом справки Hashvps; конкретные условия услуги следует отдельно сопоставить с описанием условий Hashvps. Эти материалы не заменяют проверку доступа, меток и совместимости в вашем GitHub Actions.

Если сейчас вы используете общий Runner или собственную машину, возможные недостатки различаются: общая среда может ограничивать контроль над установленными инструментами; самостоятельное обслуживание требует времени на обновления и восстановление; при временном тестировании своя машина может оставаться простаивающей между запусками. Аренда Mac у Hashvps имеет смысл, если вам нужен временный macOS-узел для проверки совместимости или ограниченного проекта и его параметры подтверждены до подключения. Сначала убедитесь, что доступ, поддерживаемая среда и жизненный цикл подходят вашему workflow. Для длительной постоянной нагрузки или требования к физическому оборудованию разумнее сравнить аренду с покупкой и собственной эксплуатацией, а если проблема только в метках или правах — исправить конфигурацию, не меняя инфраструктуру.