На сервере сборки iOS не хватает места на диске? Xcode 27: очистить или расширить

В документации Apple для Xcode отдельно описаны система сборки, путь DerivedData, компоненты среды и результаты тестов — это уже как минимум четыре разных класса данных, а не одна безымянная «кеш-папка» (система сборки Xcode, компоненты Xcode). Поэтому если на сервере сборки iOS не хватает места на диске, не начинайте с удаления всего каталога пользователя. На этой неделе сначала разделите занятое пространство на восстановимые кеши, Simulator Runtime, зависимости и релизные артефакты; расширяйте диск только тогда, когда обязательный набор инструментов и проектов уже нельзя безопасно разместить в текущей среде.

Эта статья предназначена для вас, если у вас один удалённый Mac и предупреждение о заполнении диска стало появляться перед Archive. Она также пригодится небольшой команде, которой нужно одновременно сохранять Xcode 27, несколько сред Simulator и исторические Archive, не ломая автоматическую публикацию.

Четыре слоя дискового давления

Ошибка нехватки места во время удалённой сборки часто выглядит одинаково: Archive прерывается, export не завершается, а исходный код и учётная запись разработчика при этом исправны. Причина может находиться в разных слоях:

• DerivedData и временные результаты сборки — повторно создаваемые данные проекта;
• Simulator Runtime и данные виртуальных устройств — компоненты тестовой среды и состояние конкретных симуляторов;
• кеши зависимостей — Swift Package Manager, CocoaPods и закрытые внутренние пакеты;
• релизные материалы — xcarchive, IPA, dSYM, xcresult, логи и файлы, необходимые для расследования.

Система сборки Xcode использует производные данные и настройки проекта, а расположение этих данных можно задавать через параметры сборки и xcodebuild (документация Apple о настройках сборки, пример derivedDataPath). Следовательно, одинаковая команда очистки не подходит для всех проектов: она может удалить временный результат одного приложения, но затронуть полезный кеш другого или уничтожить единственную копию материала для отладки.

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

Важно. Не очищайте диск во время Build, Test, Archive, export или загрузки результата. На удалённом Mac проверьте очередь CI, активные процессы и консоль задания; отсутствие открытого окна Xcode не доказывает, что сборка завершена.

Режим только Archive

Сервер, который занимается только Release Archive, и Mac для ежедневной разработки имеют разные границы допустимой очистки. На первом обычно не нужны все установленные Simulator Runtime и длительная история SwiftUI Preview. На втором DerivedData может ускорять повторную работу, хранить результаты промежуточной компиляции и поддерживать привычный цикл отладки.

Для Archive-сервера применяйте такой порядок:

1. Остановите расписание новых задач и дождитесь завершения текущих.
2. Сохраните идентификатор последнего успешного Archive и состояние репозитория.
3. Определите каталог DerivedData, связанный с конкретным проектом и конфигурацией.
4. Проверьте, что нужный Archive и символы отладки уже доступны из другого проверяемого источника.
5. Удаляйте только выбранный восстановимый каталог, а не весь пользовательский профиль.
6. Запустите холодную сборку и затем полный Archive.
7. Проверьте экспорт, подпись и загрузку результата так же, как после обычного релиза.
8. Только после успешной проверки возобновите расписание.

Очистка DerivedData допустима, когда вы понимаете её эффект: следующая сборка должна заново создать промежуточные результаты, поэтому нельзя считать освобождённое пространство постоянным запасом. Параметр derivedDataPath полезен и для диагностики: задайте отдельный путь для проверочного запуска, чтобы не смешивать старый и новый результат (официальный пример xcodebuild).

Если сервер используется для инкрементальной разработки, удаляйте данные не по принципу «старше определённого возраста», а по принадлежности проекту, версии Xcode и текущему статусу задачи. В противном случае автоматическое расписание может стереть результаты, которые ещё нужны параллельной ветке.

Simulator Runtime и тестовые данные

Simulator Runtime — это не то же самое, что данные созданных виртуальных устройств. Отдельно существуют установленный компонент конкретной версии системы, состояние устройства, данные приложения, снимки экрана и результаты тестов. Их нельзя объединять в одно правило очистки под названием «симуляторы».

Если сервер выполняет только Archive, установка полной матрицы Simulator может быть неоправданной. Но перед удалением проверьте схему CI: UI-тесты, скриншотные тесты и регрессионные задания могут обращаться к конкретному Runtime. Xcode позволяет управлять дополнительными компонентами среды через соответствующий раздел документации (управление компонентами Xcode).

Для тестового Mac действуйте иначе:

• составьте список поддерживаемых версий системы из реальной матрицы тестов;
• сопоставьте каждый Runtime с заданиями, которые его вызывают;
• удаляйте старые данные виртуальных устройств только после сохранения нужных результатов;
• не удаляйте Runtime, пока его версия входит в обязательный регрессионный набор;
• после очистки запустите один UI-тест и проверьте получение результата.

Симулятор не заменяет проверку на физическом устройстве. Apple прямо разделяет запуск приложения на simulated и physical devices, поэтому экономия места не должна превращаться в решение отказаться от аппаратной проверки (объяснение различий между симулятором и устройством). Особенно осторожно относитесь к тестам камеры, Bluetooth, производительности, push-уведомлений и поведения при реальных ограничениях устройства.

Зависимости нескольких проектов

На общем сервере место может исчезать не из-за одного большого Archive, а из-за нескольких проектов с разными версиями зависимостей. Swift Package Manager, CocoaPods и приватные пакеты имеют разные правила восстановления. Простое удаление всех кешей даст краткосрочный эффект, но создаст холодное разрешение зависимостей для каждого проекта и усложнит поиск причины, если один пакет больше не доступен.

Разделите учёт как минимум по трём признакам:

• проект и его репозиторий;
• версия Xcode и схема сборки;
• источник зависимости и способ восстановления.

Перед очисткой запишите lock-файлы, commit, параметры xcodebuild и адреса внутренних источников. Не храните в одном безымянном каталоге кеши, релизные продукты и резервные копии. Для повторяемой сборки важен не сам кеш, а способность получить тот же набор зависимостей из зафиксированного состояния.

Проверка после удаления должна идти непрерывной цепочкой:

1. очистить только выбранный кеш;
2. повторно разрешить зависимости;
3. выполнить сборку без использования старого промежуточного результата;
4. создать Archive;
5. проверить экспорт и подпись;
6. сохранить лог, xcresult и идентификатор commit.

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

Archive, IPA и данные для восстановления

xcarchive, IPA, dSYM и xcresult выполняют разные функции. Archive нужен для последующего экспорта и связи релизной сборки с исходным процессом. IPA — результат, который передают на установку или публикацию. dSYM участвует в расшифровке символов при анализе сбоев, а xcresult хранит сведения о выполнении тестов и диагностике. Apple отдельно описывает сборку с отладочной информацией и интерпретацию результатов тестов (документация о debugging information, результаты тестов).

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

Минимальная проверка восстановления выглядит так:

• исходный commit доступен;
• сертификаты и provisioning profile не потеряны и могут быть получены законным способом;
• зависимости разрешаются из зафиксированных источников;
• Archive можно повторить либо исходный Archive можно скачать;
• dSYM соответствует нужной сборке;
• тестовый результат и журнал доступны для анализа.

Не включайте Keychain, сертификаты, provisioning profile и релизные артефакты в правило удаления кешей. Секреты требуют отдельной политики доступа и резервирования; «очистить всё, чтобы освободить место» здесь является не оптимизацией, а риском потери возможности подписать приложение.

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

Решение: очистка, расширение или отдельный Mac

Используйте следующие условия как рабочий фильтр, а не как универсальный совет:

• Если место занято DerivedData и временными результатами завершённых задач, выберите адресную очистку и проверочную холодную сборку.
• Если место занято Simulator Runtime, который не используется текущей матрицей, выберите удаление ненужного компонента после проверки тестов.
• Если основной объём приходится на кеши зависимостей, выберите раздельное хранение и управляемое восстановление, а не ежедневное полное удаление.
• Если место занято обязательными Runtime, несколькими версиями Xcode и историческими Archive, выберите расширение диска, если эти данные действительно нужны на одном сервере.
• Если нехватка возникает только в период релиза, выберите временный отдельный удалённый Mac, чтобы не вмешиваться в единственный рабочий сервер.
• Если Archive, UI-тесты и публикация постоянно конкурируют за ресурсы и пространство, выберите разделение ролей между машинами.
• Если после очистки восстановимых данных свободное место снова быстро исчезает, не повторяйте ту же операцию бесконечно: причина уже требует изменения конфигурации или архитектуры среды.

Для низкочастотного одного приложения достаточно политики хранения и регулярной проверки источников. Для нескольких приложений с разными версиями Xcode важнее разделить рабочие среды. Для постоянных UI-тестов нужно оставить поддерживаемую матрицу Simulator. Для автоматической публикации нескольких приложений отдельный Mac часто уменьшает риск, потому что очистка тестового окружения не затрагивает выпускной процесс.

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

Контрольная процедура на этой неделе

Выполните обслуживание в таком порядке:

1. Зафиксируйте предупреждение о месте, активные задания и текущий commit.
2. Снимите перечень крупных каталогов без удаления файлов.
3. Разделите их на DerivedData, Simulator Runtime, данные устройств, кеши зависимостей, Archive, IPA, dSYM и xcresult.
4. Отметьте для каждого объекта владельца, задачу, возможность повторного создания и источник восстановления.
5. Остановите расписание и убедитесь, что Build, Test, Archive и export не выполняются.
6. Скопируйте нужные Archive, dSYM, логи и результаты тестов в проверяемое хранилище.
7. Удалите только один класс восстановимых данных за операцию, чтобы эффект можно было связать с причиной.
8. Выполните холодную сборку, тестовый запуск и Archive.
9. Проверьте экспорт, подпись, загрузку и доступность диагностических материалов.
10. Запишите результат и установите предупреждение до того, как диск снова приблизится к критическому состоянию.

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

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

См. ответы в метаданных страницы: они вынесены в отдельный сворачиваемый блок FAQ и охватывают очистку Xcode 27, допустимые к удалению файлы, регулярную обработку DerivedData, хранение Simulator Runtime и Archive, а также момент перехода к расширению.

Когда текущий сервер используется как единственная точка подписи и публикации, его нельзя обслуживать по принципу «удалить всё старое». Ограниченный диск, смешанные проекты и несколько версий Xcode создают реальные риски: повреждение текущего задания, потеря dSYM, повторное разрешение недоступной зависимости и отсутствие проверяемого Archive. Сначала создайте границы восстановления, затем выбирайте масштаб инфраструктуры.

Если нехватка места появилась из-за короткого периода релизов или проверки новой версии, аренда отдельного Mac через VPSMAC обычно удобнее, чем расширять единственный сервер и оставлять на нём все роли. Текущая машина сохраняет стабильный процесс, а временная среда принимает дополнительные Archive, тесты или новый Xcode; после завершения этапа её можно отключить без удаления критичных данных. Начать сравнение можно со страницы доступных конфигураций VPSMAC, сопоставив срок аренды с фактическим этапом разработки.