Общее время pipeline не показывает причину задержки. Один и тот же рост длительности может быть вызван увеличением LFS-набора, изменением маршрута к хранилищу, очисткой кэша, переполнением диска или реальным снижением доступной мощности Mac.

Зафиксируйте для одной базовой задачи как минимум следующие интервалы:

• получение Git-объектов и ссылок;
• загрузка LFS-объектов;
• заполнение рабочего пространства из указателей;
• восстановление зависимостей;
• подготовка Xcode и его кэшей;
• компиляция, линковка и упаковка приложения;
• ожидание свободного Runner до старта задачи.

Git LFS хранит в репозитории небольшие текстовые указатели, а сами большие файлы — отдельно. Поэтому успешный Git fetch не означает, что полноценные бинарные ресурсы уже доступны рабочему каталогу. Механизм указателей и объектов описан в официальной документации Git LFS.

Для каждой задачи сохраните Git-лог, вывод операций LFS и метрики узла. Не ограничивайтесь сообщением «checkout завершён за несколько минут». Вам нужны байты, переданные LFS, число восстановленных файлов, время ожидания и состояние диска до и после job.

Полезно иметь две базовые линии:

• холодный запуск — чистая рабочая директория и отсутствующий локальный кэш;
• повторный запуск — тот же commit, тот же набор ресурсов и сохранённый разрешённый кэш.

Сравнение этих режимов показывает, есть ли вообще эффект от повторного использования объектов. Наличие каталога кэша само по себе не доказывает его полезность: он может быть неполным, недоступным для текущего проекта или игнорироваться checkout-компонентом.

Правило первичного решения

Если наибольшая доля времени приходится на сетевое ожидание и получение LFS, сначала меняйте путь данных. Проверьте endpoint, пропускную способность, DNS, прокси, TLS-терминацию и близость хранилища к CI-узлу.

Если после загрузки ресурсов CPU или память Mac остаются насыщенными во время Xcode build, а очередь задач растёт, рассматривайте расширение Mac-пула. В этом случае дополнительные узлы решают проблему конкуренции за вычислительный ресурс, но не медленную выдачу LFS-объектов.

В Git LFS нужно различать четыре сущности:

1. Git-объект, содержащий историю, дерево и указатель.
2. LFS-указатель в рабочем каталоге.
3. Полный LFS-объект в локальном хранилище.
4. Файл, реально доступный инструменту сборки.

Эти состояния могут расходиться. Репозиторий способен успешно получить commit и указатели, но остановиться при скачивании бинарных ресурсов. Поэтому проверяйте не только код возврата checkout, но и контрольный сценарий, который открывает либо обрабатывает каждый ресурс, необходимый сборке.

Полный набор, фильтрация и разделение задач

Полный checkout оправдан для релизной задачи, если сборка действительно использует все наборы ресурсов и повторная выборка важнее экономии передачи. Для pull request-проверки такой подход часто избыточен: тестовая задача может требовать только один модуль, одну локализацию или отдельный набор медиафайлов.

Git LFS позволяет ограничивать получение объектов параметрами include и exclude. Их поведение следует проверять на изолированном репозитории и на используемой версии инструмента. Руководство по git-lfs-fetch описывает соответствующие параметры и границы их применения.

Пример диагностического фрагмента должен быть минимальным:

git lfs fetch --include="Assets/ModuleA/**" --exclude="Assets/Archive/**"
git lfs checkout

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

Отдельно проверьте:

• глубину клонирования;
• диапазон веток и ссылок, который передаёт checkout-компонент;
• обработку LFS в используемом CI action или Runner;
• повторную загрузку одинаковых объектов в разных job;
• наличие ресурсов, не связанных с текущим target;
• различие между PR-проверкой, nightly-сборкой и релизом.

Параметры clone и глубины описаны в документации Git clone, а особенности checkout следует сверять с текущей документацией actions/checkout. Не переносите поведение одного checkout-компонента на другой без теста: LFS, sparse checkout и сохранение полномочий могут обрабатываться по-разному.

Кэш LFS полезен только при контролируемом жизненном цикле. Для предприятия это не просто ускоритель, а отдельный объект инфраструктуры с правилами доверия, размера, очистки и восстановления.

Сравните три модели.

Для постоянного узла разделяйте каталог объектов LFS и каталог конкретной job. Рабочую область не следует считать валидной только потому, что в ней остались файлы от прошлого запуска. Надёжнее создавать workspace по commit и очищать его после задачи, оставляя только разрешённый объектный кэш.

Минимальный журнал кэша должен содержать:

• объём LFS-загрузки;
• количество повторно использованных объектов;
• длительность загрузки при холодном и горячем состоянии;
• объём диска до и после job;
• удалённые объекты и причину очистки;
• результат контрольной сборки после восстановления.

Не задавайте единый кэш для доверенной релизной ветки и непроверенного pull request. Даже если LFS-объекты сами по себе не являются секретом, общий каталог может облегчить вывод информации о проектах, размерах артефактов и структуре разработки. Документ о кэшировании зависимостей в CI отдельно подчёркивает необходимость оценивать границы доступа и риск утечки через кэш.

Сценарий из практики платформенной команды

Представьте репозиторий, где PR-задача компилирует основной target, но checkout каждый раз получает ресурсы приложений, демонстрационные материалы и архивные наборы. В такой ситуации рост общего времени не доказывает деградацию Mac: машина может простаивать, пока job ждёт LFS endpoint.

Решение состоит не в немедленной покупке ещё одного узла. Сначала команда отделяет объектный кэш от workspace, ограничивает набор ресурсов для PR, а релизную задачу оставляет полной. Затем она повторяет один commit в холодном и горячем режимах и проверяет, что итоговый архив содержит все требуемые файлы. Только после этого имеет смысл сравнивать очередь и загрузку Mac.

Ускорение не должно менять смысл сборки. Для каждого режима зафиксируйте, что job получает полноценные LFS-файлы, а не указатели. Проверка должна быть воспроизводимой: один commit, один набор параметров и контрольный тест, который обращается к критическим ресурсам.

Разделяйте как минимум четыре типа доступа:

• чтение Git-репозитория;
• чтение LFS-объектов;
• запись артефактов и кэша;
• доступ к сертификатам и ключам подписи.

Токен для получения ресурсов не должен автоматически давать право на подпись релизного приложения. Непроверенная ветка не должна наследовать постоянные полномочия производственного узла. Для self-hosted Runner дополнительно оцените, кто может отправить задачу на конкретную машину, какие переменные среды сохраняются и как очищаются логи.

Рекомендации по безопасному использованию self-hosted Runner полезны как контрольный список для маршрутизации заданий, доверия к репозиториям и защиты узла. Установка Git LFS также должна быть явной и проверяемой; порядок настройки приведён в официальном руководстве git-lfs-install.

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

После оптимизации checkout измеряйте уже не только время одной job. Для планирования нужны:

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

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

Условия выбора архитектуры

Фиксированный Mac-пул подходит, если:

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

Эластичный пул удалённых Mac разумен, если:

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

Гибридная схема обычно лучше для предприятий с релизными ограничениями: постоянные доверенные Mac остаются для подписи и чувствительных задач, а временные удалённые узлы принимают PR, тестовые сборки и подтверждённые пики. Перед решением можно изучить варианты удалённых Mac для CI/CD и проверить их на том же репозитории, а не на синтетическом проекте.

Результат пилота должен быть не фразой «стало быстрее», а матрицей с доказательствами. Для каждой проверки укажите commit, параметры checkout, состояние кэша, логи, итог и действие при отказе.

TCO считайте переменными, а не неподтверждёнными суммами:

TCO = трафик LFS + хранение кэша + занятое время Mac + часы эксплуатации + стоимость влияния сбоя.

В «трафик LFS» включайте только реально переданные данные по выбранному периоду. В «занятое время Mac» — и активную сборку, и подтверждённое ожидание, если ресурс нельзя использовать для другой job. В «стоимость влияния сбоя» — задержку релиза, ручное восстановление и повторные pipeline.

Такой расчёт позволяет сравнить покупку узлов, постоянный пул и аренду без выдуманных тарифов. Для пробного сравнения конфигураций Mac можно использовать страницу оформления Mac mini, но итоговое решение принимайте только после запуска собственного iOS pipeline и проверки требований к данным, доступу и региону.

Почему время checkout растёт при неизменном времени компиляции?

Чаще всего меняется объём LFS-объектов, диапазон refs или состояние кэша. Проверьте состав переданных байтов и количество восстановленных файлов по одному commit. Если Xcode по-прежнему компилирует за прежнее время, увеличение общего pipeline нельзя считать проблемой мощности Mac.

Как отделить проблему Git LFS от проблемы сети?

Сравните время получения обычных Git-объектов, LFS-загрузки и заполнения workspace. Затем повторите задачу с тем же commit в холодном и горячем режимах. Большая разница при одинаковой загрузке CPU указывает на путь данных или кэш, а не на недостаток вычислительных узлов.

Можно ли оставить постоянный кэш на общем Runner?

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

Когда расширение Mac-пула действительно оправдано?

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

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

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

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