Что делать, если на удалённом Mac CI не хватает места на диске? Руководство по диагностике 2026

Сначала выясните, что именно занимает диск — DerivedData, архивы, данные симуляторов или рабочий каталог, — и очищайте только то, что вы проверили как восстанавливаемое. Если проблема повторяется на самоуправляемом Runner, добавьте контроль свободного места и уборку конкретных каталогов после заданий: удаление всей папки разработчика не является универсальным исправлением.

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

Сначала определите, что именно отказало

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

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

Сначала проверьте файловую систему и каталоги, не удаляя файлы:

df -h /
du -sh "$HOME/Library/Developer/Xcode/DerivedData"
du -sh "$HOME/Library/Developer/Xcode/Archives"
du -sh "$HOME/Library/Developer/CoreSimulator"
du -sh "$HOME/actions-runner/_work"

Путь ~/actions-runner/_work здесь приведён как пример расположения каталога: у вашего Runner рабочий путь может быть другим. Подставляйте фактический путь из конфигурации задания. Команды du сообщают размер указанных каталогов, а df — состояние файловой системы; это разные измерения. Проверьте права доступа и учитывайте, что каталоги могут находиться на другом томе. Если путь отсутствует или команда не имеет доступа, не трактуйте это как нулевой размер.

Для системного обзора можно открыть настройки хранилища macOS, но разбивка по категориям сама по себе не устанавливает точный источник роста. Сверяйте её с измерениями реальных каталогов и журналом задания. Инструкция Apple по проверке хранилища Mac описывает просмотр доступного пространства и данных хранилища; она не заменяет проверку конкретного рабочего каталога CI.

Найдите крупные каталоги без догадок

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

Сценарий: сборка падает на записи, хотя предупреждение macOS указывает на другую категорию. Инженер видит, что рабочая директория содержит оставшиеся результаты нескольких проектов, а DerivedData выглядит умеренно. В этом случае нужно проверять фактические каталоги и настройки сохранения артефактов, а не удалять всё, что связано с Xcode.

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

Разделите DerivedData и Archives перед очисткой

DerivedData и Archives — разные наборы данных. Apple описывает DerivedData как место для данных сборки, индексации и журналов. Архивы Xcode предназначены для сохранения результатов архивации, которые могут потребоваться для распространения, диагностики или повторной проверки приложения. Их нельзя считать одной временной папкой.

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

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

Не удаляйте целиком ~/Library/Developer и не используйте массовое удаление по маске, пока не подтвердили, какие проекты, архивы и компоненты Xcode находятся внутри.

Подход с точечной очисткой имеет преимущества и ограничения:

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

Проверьте симуляторы и результаты тестов

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

Проверьте список доступных сред и устройств штатными средствами Xcode и simctl. Например:

xcrun simctl list runtimes
xcrun simctl list devices

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

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

Проверьте, относится ли проблема к Runner

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

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

Спроектируйте уборку с понятными границами:

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

Если CI использует контейнеры, изучите, что именно сохраняется между заданиями и где размещены данные контейнеров. GitHub отдельно описывает настройку контейнеров для self-hosted Runner. Наличие контейнерного задания не означает, что данные автоматически изолированы от диска хоста: проверьте фактическое размещение и правила очистки.

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

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

Используйте последовательную проверку:

• [ ] Запишите свободное место и размеры выбранных каталогов до изменения.
• [ ] Подтвердите владельца и назначение каждого каталога, который собираетесь очистить.
• [ ] Удаляйте только данные, восстановление которых проверено для вашего рабочего процесса.
• [ ] После каждого типа очистки повторите измерения, не смешивая результаты разных действий.
• [ ] Запустите сборку и тест, соответствующие обычной нагрузке проекта.
• [ ] Если процесс выпуска требует архива, проверьте его создание и сохранение.
• [ ] Проверьте, что следующее задание Runner начинает работу без потери нужного состояния.
• [ ] Сохраните журнал ошибки, измерения и результат повторного запуска для будущего сравнения.

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

Если вы параллельно настраиваете доступ к машине, используйте руководство по помощи и настройке доступа MangoVM. Для постоянной работы с удалённой средой заранее определите, как команда обращается с файлами и учётными данными; соответствующие правила описаны в разделе защиты данных MangoVM.

Частые вопросы о нехватке места в CI

Как искать причину, если Xcode сообщает о нехватке места?

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

Можно ли просто удалить DerivedData?

Не удаляйте каталог вслепую. Установите, какой проект и какой Xcode использует данные, и проверьте, можно ли заново получить необходимое содержимое. Очистка выбранной DerivedData может быть допустимой, если данные пересоздаются, но она способна вызвать повторную индексацию и сборку. Archives, компоненты Xcode и каталоги других проектов проверяйте отдельно.

Как остановить рост данных на self-hosted Runner?

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

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

Сопоставьте доступные среды и устройства с тем, что требует проект; затем проверьте свободное пространство после очистки. Запустите обычную для проекта сборку и тесты на требуемом симуляторе. Если выпуск зависит от архивации, проверьте и её, а также сохранение результата. Успешный старт компиляции без тестирования и записи требуемых артефактов не подтверждает восстановление всего CI-процесса.

Если после проверки причина — в постоянной нагрузке, а не в оставшихся восстановимых файлах, сравните необходимую ёмкость с возможностями текущей машины. Локальный Mac удобен, когда важны физический доступ и долгосрочная непрерывная нагрузка; собственный хост требует самостоятельного обслуживания и контроля остатка диска. Для временного проекта или проверки macOS-сборки аренда Mac у MangoVM может избавить от покупки отдельной машины, но сначала убедитесь, что удалённый доступ и характеристики выбранной среды подходят вашему CI. Посмотрите доступные варианты на странице MangoVM, а затем повторите проверку на representative workload проекта, прежде чем переносить постоянные задания.

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