Xcode Cloud постоянно стоит в очереди? Руководство по диагностике 2026

Данные App Store Connect API выделяют три значения хода сборки: PENDING, RUNNING и COMPLETE (определение Apple). Вывод: если сборка Xcode Cloud стоит в очереди, сначала выясните, действительно ли она ожидает запуска; затем проверьте триггеры workflow и Apple Developer System Status. Не считайте ожидание доказательством ошибки проекта. Если эти проверки не объясняют задержку, испытайте независимый процесс на Mac — он даст резервный путь, но не ускорит сервис Apple.

Кому пригодится эта диагностика

Независимым разработчикам, чья сборка Xcode Cloud долго не запускается и которым нужно различить ожидание, пропуск и ошибку.
Инженерам CI, проверяющим условия запуска workflow и историю сборок.
Ответственным за выпуск, которым важно подтвердить резервный процесс до следующего релиза.

Сначала определите, на каком этапе остановилась сборка

Фраза «всё ещё в очереди» может описывать разные ситуации: событие коммита не запустило workflow, сборка ожидает исполнения или уже завершилась с конкретным результатом. Для диагностики нужна запись конкретного запуска и его официальные поля состояния. Одно уведомление или надпись в списке не позволяют достоверно установить причину.

В документации API Apple отдельно описаны ход исполнения и итоговый статус: это разные поля, отвечающие на разные вопросы. У CICompletionStatus перечислены пять исходов — SUCCEEDED, FAILED, ERRORED, CANCELED и SKIPPED (официальное описание completion status). Сверяйте значение в записи сборки, а не выводите результат по одному лишь факту, что workflow не выдал артефакт.

Статусы и их трактовку подтверждают справочник записей build runs. Названия в интерфейсе могут быть представлены иначе, поэтому сопоставляйте видимое состояние с определением Apple. Разделяйте ход сборки и её результат: PENDING или RUNNING описывают продвижение процесса, а значения completion status показывают, чем закончилась запись после завершения или прекращения исполнения.

Если записи сборки нет, начните с триггеров workflow

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

В справочнике Apple описаны, среди прочего, два типа событий, на которые может реагировать workflow: изменения в выбранной ветке и события, связанные с pull request. Какие условия сработают, определяется конфигурацией конкретного workflow, а не самим фактом появления коммита (справочник workflow Xcode Cloud).

Проверьте конфигурацию последовательно:

• Убедитесь, что workflow включён и относится к нужному приложению.
• Сверьте ветку текущего коммита с ветками, заданными как триггеры. Похожее имя ветки не означает, что она включена в правило.
• Определите, на какое событие рассчитывает команда: обновление ветки, создание или обновление pull request либо другое доступное условие.
• Уточните, включены ли нужные схема и конфигурация в workflow; проверьте его действия и настройки тестирования.
• Сопоставьте текущий коммит с последним успешным запуском: есть ли запись для нового события, и на каком именно шаге история разошлась.

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

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

Отмена и пропуск: проверьте Auto-cancel Builds

Если в истории указан CANCELED или SKIPPED, не относите это автоматически к ошибке компилятора. Просмотрите соседние запуски и порядок коммитов. При включённом Auto-cancel Builds новый запуск может повлиять на предыдущую сборку согласно настройке workflow. Это важно при частых обновлениях одной ветки: результатом может стать отмена или пропуск устаревшего запуска, а не ошибка кода.

Проверяйте именно тот workflow, к которому относится запись, и сопоставляйте результат с настройкой Auto-cancel Builds. Затем посмотрите, появился ли более поздний запуск для нового коммита. Apple описывает настройки workflow и соответствующее поведение в справочнике Xcode Cloud. Не отключайте автоматическую отмену только ради того, чтобы в истории стало больше завершённых запусков: сначала решите, нужно ли команде собирать каждый промежуточный коммит или только актуальное состояние ветки.

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

Если выполнение началось или завершилось ошибкой, переходите к журналу

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

Проверяйте по этапам:

• Подготовка проекта. Убедитесь, что workflow выбрал ожидаемую схему и конфигурацию, а нужные файлы доступны в репозитории.
• Зависимости. Проверьте, что CI может получить пакеты и другие зависимости, необходимые проекту. Для Swift-пакетов и проектов, использующих их, Apple описывает требования в руководстве по сборке в CI.
• Секреты и доступы. Сверьте переменные и разрешения, используемые workflow. Не переносите секреты в журналы и не публикуйте их при подготовке воспроизведения.
• Сборка и тесты. Отделите ошибку компиляции от сбоя теста или последующего действия. Запишите, на каком действии процесс впервые вышел за ожидаемый результат.
• Конфигурация среды. Сопоставьте настройки с рекомендациями Apple по типичным проблемам сборки и конфигурации.

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

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

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

Сверьте сервисы Apple и задайте точку эскалации

Откройте Apple Developer System Status и проверьте, указаны ли проблемы у сервисов, связанных с Xcode Cloud. Оценивайте состояние на момент инцидента, а не по сохранённому скриншоту или записи из обсуждения: страница может обновиться, а пользовательские сообщения описывают отдельные случаи и сами по себе не устанавливают общую причину.

Отсутствие предупреждения на странице статуса не доказывает, что с конкретной сборкой, аккаунтом или серверной обработкой всё в порядке. Но и ожидание без дополнительной проверки не подтверждает сбой Apple. Чтобы подготовить обращение по официальному каналу, сохраните:

• ссылку или идентификатор build run;
• состояние и время его изменения;
• репозиторий, ветку и коммит, относящиеся к запуску;
• имя workflow и событие, которое должно было его активировать;
• выдержку из журнала без паролей, токенов и других секретов;
• результат проверки системного статуса.

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

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

Проверка резервного пути: тот же коммит, отдельная машина

Резервный процесс нужен для ответа на практический вопрос: способен ли проект собраться и пройти необходимые проверки вне Xcode Cloud? Это не способ исправить очередь внутри сервиса и не гарантия эквивалентности двух сред.

Проверку проводите без смешения изменений:

1. Возьмите тот же коммит, который ожидал запуска в Xcode Cloud.
2. Зафиксируйте используемую версию Xcode и параметры схемы.
3. Установите зависимости тем способом, который предусмотрен для проекта.
4. Запустите нужные сборочные действия и тесты.
5. Проверьте подпись и получение результата, если они входят в процесс выпуска.
6. Сохраните журналы и сравните первое различие с запуском Xcode Cloud.

Для инженерного теста подойдёт отдельный Mac, к которому команда получает доступ для сборки и проверки. Например, можно рассмотреть удалённый Mac на Apple Silicon, предварительно уточнив соответствие проекта требованиям и проверив весь путь от коммита до артефакта. В документации armrdp можно изучить сведения о доступе к удалённой машине. Наличие другой машины само по себе не подтверждает, что резервный CI уже готов к выпуску: это устанавливает только проверка на проекте.

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

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

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

FAQ: практические развилки при диагностике

Долгое ожидание всегда означает ошибку проекта?

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

Как понять, что проблема в настройке, а не в сервисе?

Сверьте ветку и событие коммита с правилами workflow. Проверьте, появился ли запуск и каково его состояние. Затем откройте системный статус Apple. Ошибка конфигурации становится вероятнее, если ожидаемое событие не подходит условиям запуска; отметка о проблеме сервиса важна, но отсутствие такой отметки не является доказательством, что серверная причина исключена.

Как убедиться, что старый запуск не отменён новым?

Проверьте completion status, Auto-cancel Builds и соседние записи в истории. Если старый запуск получил CANCELED или SKIPPED, сравните его с более поздним запуском и соответствующим коммитом. Такое состояние не говорит само по себе, что проект не собрался: важно понять, завершилась ли более новая сборка и соответствует ли она нужному исходному коду.

Что должно подтвердить пригодность резервного процесса?

Минимальная проверка — сборка того же коммита и прохождение требуемых проектом тестов на отдельной машине Mac. Если выпуск требует подписи, проверьте её и способ передачи результата. Сохраните параметры Xcode, схему и журналы, чтобы команда могла повторить тест. Успешная резервная сборка подтверждает независимый путь для проекта, но не устраняет задержку Xcode Cloud.

Когда имеет смысл подключать отдельный Mac

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

Для временной проверки проекта, сборки перед релизом или подтверждения альтернативного CI удалённая аренда Mac может быть гибче покупки машины сразу. Но решение стоит принимать после теста на том же коммите и сверки доступа, инструментов и процесса получения артефакта. Если нужен такой тестовый контур, изучите доступный вариант Mac на Apple Silicon и проверьте на нём именно свой workflow. Это создаст отдельный путь сборки; очередь Xcode Cloud по-прежнему диагностируется отдельно.

Часто задаваемые вопросы