Руководство

Пайплайн CI/CD для iOS на своей машине

Большинство советов по iOS CI оптимизируют не то. Минуты уходят вовсе не на шаг сборки. Здесь описано, что реально помогает в настоящем пайплайне и как выделенное железо меняет расчёт.

Куда на самом деле уходят минуты

На hosted раннере типичная задача iOS тратит много времени ещё до того, как скомпилирует хоть одну строку вашего кода. Она разрешает и скачивает зависимости, наполняет пустую папку DerivedData, устанавливает инструменты и загружает симулятор. Эта работа повторяется при каждом запуске, потому что машину потом уничтожают.

На выделенной машине эта работа в основном уже сделана. В нашем тесте на iOS-приложении Wikipedia чистая сборка на M6 mini прошла на 53 процента быстрее, чем на стандартном раннере GitHub. Типичная задача CI сократилась с 269 секунд до 27. Выделенный Mac сохранил папку сборки и пересобрал только изменённое.

Пайплайн, который стоит повторить

  • Разделите работу. Линтер, тесты общих Swift-пакетов и автоматизация релизов могут идти на Linux. На Mac оставьте только работу с симулятором и устройствами.
  • Кэшируйте правильные пути. DerivedData, SwiftPM, CocoaPods и Gems. На выделенной машине они сохраняются бесплатно.
  • Отдайте рутину fastlane. Lanes для сборки, тестов, скриншотов и загрузки дают одинаковые команды локально и в CI.
  • Сделайте подпись предсказуемой. fastlane match с приватным репозиторием сертификатов всё ещё самый надёжный подход. MacRun не управляет подписью за вас. Зато и сюрпризов нет.
  • Урежьте матрицу. Полным матрицам устройств и версий ОС место на main и в ночных запусках, а не в каждом pull request.

Пример workflow

name: iOS
on: [pull_request]

jobs:
  test:
    runs-on: [self-hosted, macOS, macrun-unit-01]
    steps:
      - uses: actions/checkout@v4
      - run: sudo xcodes select 26.6
      - run: bundle install
      - run: bundle exec fastlane test

Раннер выделенный, поэтому шага восстановления кэша здесь нет. Зависимости и DerivedData с прошлого запуска уже лежат на диске.

Чего это не решает

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

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

Как ускорить сборки iOS в GitHub Actions?

+

Сначала уберите повторяющуюся подготовку, а потом оптимизируйте компиляцию. Сохраняйте кэши DerivedData, SwiftPM и CocoaPods. Переносите работу без Mac на раннеры Linux. Урезайте матрицы устройств в pull request и зафиксируйте одну версию Xcode. На выделенном железе кэши сохраняются между запусками сами.

Можно ли использовать fastlane на self-hosted раннере macOS?

+

Да. fastlane, CocoaPods, Ruby и Node уже установлены на машинах MacRun. Вы вызываете их так же, как локально. Подпись через fastlane match работает так же, как на любом Mac.

MacRun берёт на себя подпись кода?

+

Нет, и это сознательно. Сертификаты и профили подготовки остаются под вашим контролем, обычно через fastlane match с вашим приватным репозиторием. Мы даём машину, а не управляемый сервис подписи.

Можно ли запускать UI-тесты iOS на выделенном раннере?

+

Да. Симуляторы работают как обычно. Машину не пересоздают, поэтому состояние загрузки симулятора и данные сборки остаются прогретыми между запусками. Обычно это экономит несколько минут на каждой задаче с UI-тестами.

Похожие руководства