Симптом: на Mac-узле Jenkins появляется предупреждение о свободном месте или сборка завершается ошибкой записи. Быстрое решение: сначала установите, что заняло диск — рабочие каталоги, компоненты Xcode или артефакты, — затем очистите только подтверждённые данные. Не удаляйте каталоги массово; если проблема возвращается после безопасной очистки, решайте по журналам, менять ли правила хранения или сам узел.
Эта инструкция для IT-руководителей, которым нужно понять, угрожает ли дисковая тревога стабильности CI. Она также пригодится инженерам, отвечающим за Jenkins Mac Agent, workspace и окружение Xcode. Техническим директорам и руководителям эффективности разработки материал поможет обосновать выбор между изменением очистки и пересмотром ресурсов Mac CI.
Сначала отделите предупреждение о диске от сбоя сборки
Предупреждение о малом запасе места, ошибка записи и упавшая сборка — связанные, но не тождественные события. Агент может сообщать о заполненном томе, когда конкретный job ещё не обращался к нему с записью; сборка же может завершиться из-за сети, очереди, недоступного инструмента или ошибки проекта. Не начинайте с удаления файлов по одному сообщению в консоли.
Сопоставьте состояние тома и журнал задачи за один и тот же временной интервал. Зафиксируйте свободное место, путь, где возникла ошибка, стадию сборки, имя агента и то, выполнялись ли параллельные задания. Команда df -h показывает занятость подключённых файловых систем в удобном для чтения формате. Затем исследуйте объём отдельных каталогов, например с помощью du -sh или du -xhd 1 /путь; второй вариант помогает разбить один уровень каталога и ограничить обход текущей файловой системой. Если параметр глубины не поддерживается установленной версией macOS, используйте доступный вариант du и проверяйте каталог за каталогом.
| Наблюдение | Что проверить | Оценка вероятности причины по имеющимся данным | Следующий шаг |
|---|---|---|---|
| Сборка остановилась при записи или распаковке | Свободное место на томе, путь ошибки и одновременные jobs | Высокая, если ошибка записи совпадает по времени с заполнением тома | Найти каталог-владелец и определить, что в нём можно удалить |
| Есть предупреждение, но сборки проходят | Порог и источник сигнала, рост занятого места, новые задания | Средняя: одного предупреждения недостаточно для диагноза | Собирать показатели по агенту и задачам, не чистить вслепую |
| Сборка упала без ошибки диска | Очередь, сеть, доступность Xcode и сообщения job | Низкая, пока нет подтверждённой ошибки записи | Разбирать журнал как отдельный сбой |
| Диск быстро заполняется повторно | Workspace, параллельные каталоги, артефакты и журналы | Высокая, если рост повторяется после очистки | Зафиксировать прирост по источникам и пересмотреть правила хранения |
Не ограничивайтесь одним df -h, если на узле несколько томов или путей хранения. Проверьте, куда направлены workspace, временные файлы, архивы и журналы, и на каком именно томе возникло ограничение. Несовпадение пути ошибки и каталога, который вы очищаете, — основание остановиться и перепроверить диагностику.
Найдите остатки workspace, не потеряв данные для разбора
Начните с пути Jenkins workspace, затем определите, какие каталоги принадлежат действующим заданиям, а какие остались после завершённых или прерванных запусков. Параллельные сборки могут создавать несколько рабочих каталогов; не считайте каждый из них бесполезным только потому, что он не совпадает с именем основной задачи. Сверьте владельца, время последнего изменения и связь с конкретным build.
Для очистки в Jenkins есть шаг Workspace Cleanup: он позволяет настраивать удаление рабочего пространства из Pipeline. Изучите параметры и оговорки в документации шага cleanWs. Внедряя его, определите точное место выполнения и условия, при которых он срабатывает. Например, шаг в блоке post и очистка только после успешной сборки дадут иное поведение, чем очистка после любого результата. Обсудите, какой вариант соответствует вашей процедуре диагностики, и проверьте настройки по синтаксису Jenkins Pipeline.
Не удаляйте workspace неуспешной сборки, пока не поняли, какие сведения команда использует для воспроизведения сбоя: там могут оказаться промежуточные результаты, входные данные или контекст, которого нет в журнале Jenkins. Если доказательства нужны, сначала предусмотрите их сохранение вне очищаемого каталога и подтвердите, что доступ к ним ограничен принятой политикой. Хранение не должно быть неявным: назначьте владельца данных, причину сохранения и процедуру удаления.
Практический порядок проверки:
- определите фактический путь workspace для каждого проблемного job;
- сопоставьте каталоги с завершёнными, активными и прерванными заданиями;
- проверьте, не выполняется ли сборка параллельно с очисткой того же пути;
- решите, какие файлы нужны для диагностики или воспроизведения;
- внесите ограниченное правило очистки и проверьте его на выбранных job.
Разберите компоненты Xcode и Simulator runtime отдельно
Не объединяйте Xcode, дополнительные компоненты, платформенную поддержку и Simulator runtime в одну категорию «кэш». У них разные назначения и зависимости. Сначала выясните, какие версии Xcode, платформы и симуляторы нужны сборочным заданиям, включая тестирование веток и выпусков. После этого проверьте установленные компоненты средствами Xcode.
Apple документирует управление платформенной поддержкой, дополнительными компонентами и Simulator runtime в руководстве по загрузке и установке компонентов Xcode. В нём предусмотрено удаление или отключение ненужных компонентов для возврата места. Доступные runtimes и варианты управления ими также описаны в материале Apple о дополнительных симуляторах. Ориентируйтесь на эти способы, а не на ручное удаление каталогов, которые macOS защищает или которыми управляет Xcode.
| Объект | Что выяснить до изменения | Допустимое действие | Риск при поспешном удалении |
|---|---|---|---|
| Сам Xcode и его выбранная версия | Какие задания вызывают эту установку и какой путь задан агенту | Не удалять используемую установку без плана переключения и проверки | Агент не найдёт ожидаемый инструмент или сборка использует другой toolchain |
| Platform support и дополнительные компоненты | Какие платформы требуются проектам и заданиям | Удалять ненужные компоненты средствами управления Xcode | Ошибка при подготовке сборки или проверке проекта |
| Xcode Simulator runtime | Какие версии симуляторов реально выбирают тесты | Удалить только подтверждённо неиспользуемый runtime через поддерживаемое управление Xcode | Тесты не смогут запуститься в требуемой среде |
| DerivedData и временные данные | Можно ли воспроизвести сборку и восстановить данные повторным запуском | Очищать адресно, после проверки зависимостей и политики команды | Увеличение времени повторного запуска либо потеря диагностического контекста |
Разведите архивы, журналы и прочие результаты сборок
Артефакты требуют отдельной политики. Архивы выпуска, символы, тестовые отчёты и журналы могут понадобиться для распространения приложения, аудита, диагностики или подтверждения состояния релиза. Кэш и временные выходные данные обычно можно восстановить повторной сборкой, но и здесь сначала проверьте, что именно создаёт ваш процесс. Не называйте всё «мусором» только потому, что оно не находится внутри workspace.
Для каждого типа данных зафиксируйте назначение, владельца, место хранения и условие удаления. Если архив или диагностические материалы должны сохраняться вне агента, убедитесь, что перенос действительно завершился и результат доступен тем, кому он нужен. Не удаляйте исходную копию только потому, что pipeline запустил шаг публикации: статус шага сам по себе не подтверждает доступность выгруженного файла.
Управление хранением можно проверить в такой последовательности:
- найдите пути архивов, отчётов, символов и журналов в конфигурации jobs;
- установите, какие данные нужны для публикации, расследования сбоев и требований аудита;
- проверьте фактическое наличие копии в целевом хранилище до удаления с Mac;
- задайте владельца и проверяемое правило хранения для каждого класса артефактов;
- испытайте удаление на выбранном задании, затем проверьте возможность восстановления.
| Данные | Обычно требуется сохранить, если… | Перед удалением подтвердите |
|---|---|---|
| Архив выпуска | Он связан с опубликованной версией или нужен для повторного распространения | Архив доступен в утверждённом хранилище и известен его владелец |
| Символы и crash-материалы | Они нужны для анализа сбоев пользователей или релизной поддержки | Сохранены соответствующие символы и их можно найти по версии |
| Отчёт тестирования и журнал | По ним разбирают отказ, подтверждают результат или ищут регрессию | Данные доступны вне каталога, который очищает job |
| Восстанавливаемый кэш | Команда подтвердила возможность пересоздать его штатной сборкой | Повторный прогон проходит с ожидаемыми зависимостями |
Перед включением очистки проверьте риск для воспроизводимости
Очистка, которая высвободила место, ещё не доказала, что она безопасна. Изменение workspace может удалить материалы для разбора ошибки; удаление компонента Xcode — нарушить выбор среды; удаление артефакта — сделать недоступным релизное доказательство. Для команды важен не только факт успешного завершения следующей сборки, но и сохранение диагностического пути, нужных зависимостей и возможности повторить результат.
Перед распространением правила очистки используйте список допуска:
- [ ] Источник занятого места подтверждён измерением и связан с конкретным томом.
- [ ] У каждого удаляемого каталога определены владелец и назначение.
- [ ] Выбранные для удаления данные не требуются активным или параллельным заданиям.
- [ ] Диагностические материалы и обязательные артефакты сохраняются либо перенесены и проверены.
- [ ] Удаление workspace ограничено нужным job и не затрагивает соседние задания.
- [ ] Состав Xcode и Simulator runtime после изменений соответствует настройкам тестов.
- [ ] Успешная, неуспешная и прерванная сборка проверены на тестовом сценарии.
- [ ] Есть способ вернуть прежнюю конфигурацию, если очистка ломает сборку.
Решайте по журналам, когда менять правила или узел
Если после очистки диск снова заполняется, соберите репрезентативную последовательность запусков и сравните, откуда растёт занятое место. Учитывайте частоту создания workspace, одновременную работу заданий, объём сохраняемых архивов и то, как часто нужны старые материалы для расследований. Не выводите требуемый объём диска из одного пикового значения: оно может соответствовать редкому релизному заданию, а может повторяться при обычной нагрузке.
| Признак по журналам | Что изменить сначала | Когда рассматривать другой Mac-узел |
|---|---|---|
| Остатки workspace растут после завершённых заданий | Адресное правило очистки и проверку пути выполнения | Если безопасная очистка мешает диагностике или не устраняет повторяющиеся сбои |
| Занятость связана с ненужными компонентами Xcode | Уточнить поддерживаемый набор платформ и runtimes | Если требования разных проектов нельзя разумно обслужить текущей конфигурацией |
| Основной объём — релизные артефакты и журналы | Перенести и организовать хранение с проверкой доступности | Если подтверждённые требования к сохранению постоянно превышают возможности узла |
| Рост совпадает с параллельными или тяжёлыми заданиями | Проверить расписание, изоляцию и распределение работ | Если фактическая нагрузка регулярно конфликтует с политикой хранения и доступным ресурсом |
Если пригодность точечной очистки высокая и после испытания сохраняются нужные данные, начните с неё. Если очистка лишь переносит сбой, потому что рабочие требования и политика хранения несовместимы с текущей нагрузкой, сравните изменение расписания и распределения задач с добавлением или заменой Mac CI-узла. Заранее определите, какие записи подтвердят улучшение: ошибки записи, состояние томов, результаты сборок и соблюдение сроков хранения. Не обещайте прирост производительности или экономию без измерения на ваших заданиях.
Для такой оценки отделяйте техническую проблему от закупочного решения. Обзор доступных вариантов MACGPU и информация о стоимости аренды Mac помогут изучить удалённое размещение, но сравнение имеет смысл только с учётом вашей нагрузки, требований к данным и процесса закупки. До выбора подтвердите, какие конфигурации доступны, как устроена передача доступа и подходит ли модель аренды правилам вашей организации; не подменяйте эти проверки неподтверждёнными обещаниями по ёмкости или затратам.
Частые вопросы
Какие каталоги на Jenkins Mac Agent проверять в первую очередь?
Начните не с удаления файлов, а с сопоставления показаний df -h и размеров каталогов рабочего пространства, Xcode и хранилища артефактов. Проверьте Jenkins workspace, DerivedData, локальные архивы и журналы сборки; для каждого найденного объёма выясните владельца, задачу, срок хранения и возможность повторного создания. Не удаляйте каталоги только потому, что они велики.
Можно ли удалить неиспользуемый Xcode Simulator runtime?
Да, если вы подтвердили, что используемые проекты, тестовые задания и активные ветки не требуют этой версии среды. Сначала инвентаризируйте доступные runtimes и зависимости заданий, затем управляйте компонентами через настройки Xcode и предусмотренный Apple способ удаления. После очистки запустите тесты с нужными симуляторами; ручное удаление защищённых системных каталогов не подходит как универсальная процедура.
Удаление Jenkins workspace не сотрёт файлы, нужные для диагностики?
Может стереть: в рабочем каталоге могут оставаться промежуточные файлы, журналы или сведения, необходимые для воспроизведения сбоя. До включения очистки определите, какие данные сохраняются отдельно и кто ими пользуется при разборе инцидентов. Проверьте поведение задания после успешной сборки, ошибки и прерывания, а очистку ограничьте конкретным workspace или правилами исключения.
Когда после очистки пора менять или расширять Mac CI-узел?
Рассматривайте смену или добавление узла, если повторяющиеся записи показывают устойчивый рост нужных для работы данных, а безопасная очистка не устраняет сбои без потери артефактов и диагностических материалов. Сначала сопоставьте расход места с заданиями, параллельностью, сроками хранения и восстановлением после ошибки. Не выводите решение из одного предупреждения или абстрактного порога заполнения.
Если вы уже проверили workspace, Xcode и артефакты, но текущая схема требует постоянных ручных чисток, сравните её с удалённым Mac по реальным ограничениям: самостоятельное оборудование связывает бюджет с закупкой и обслуживанием, локальный узел зависит от доступности и ухода, а неуправляемая очистка грозит потерей нужных данных. При временной потребности в дополнительной среде или пилотном CI-узле аренда Mac у MACGPU может быть вариантом для оценки — при условии, что удалённый доступ и правила работы с данными соответствуют требованиям вашей команды. Если нагрузка постоянная, тяжёлая или требует физических подключений, сначала проверьте, не рациональнее ли собственный узел.