В документации fastlane описаны два режима синхронизации match — обычный и readonly; второй предназначен для получения существующих подписывающих активов без их создания или изменения (документация fastlane match). Поэтому успешная синхронизация ещё не доказывает, что подпись на удалённом Mac заработает. Сначала проверьте, что закрытый ключ доступен именно учётной записи сборки, затем сопоставьте iOS Provisioning Profile с настройками проекта и подтвердите результат настоящим Archive. Для CI и штатной публикации используйте readonly, если набор активов уже подготовлен; не начинайте с отзыва или пересоздания сертификатов.
Статья предназначена независимым разработчикам, которые перенесли fastlane-сборку на удалённый Mac и проверяют, что фактически использует задача.
Она также пригодится небольшим командам, разделяющим первоначальную подготовку подписи и регулярный CI-процесс.
Если Archive завершается ошибкой, здесь можно последовательно отделить проблему ключа от профиля, настроек проекта и доступа к учётным данным.
Ошибка подписи fastlane match на удалённом Mac: границы синхронизации
Успешный вывод match подтверждает лишь часть цепочки. Между получением сертификата и профиля и подписанием приложения остаются отдельные проверки: задаче нужны доступ к исходным данным и материалу расшифровки, пригодная подписывающая личность с закрытым ключом, подходящий профиль и согласованные параметры сборки. Наличие файла профиля на диске не означает, что Xcode выбрал его для нужной цели.
При переносе сборки важно сравнивать не абстрактное «локально» и «в облаке», а конкретное исполнение: какая учётная запись запускает процесс, какой проект и target собираются, какие настройки конфигурации применены и на каком этапе проявляется ошибка. Графический сеанс разработчика и фоновая задача могут выполняться с разными правами и доступом к связкам ключей. Из-за этого ситуация «вручную подписывает, CI не подписывает» сама по себе не указывает на неисправность сертификата.
Разделите цепочку на самостоятельные объекты:
- Учётные данные репозитория match дают доступ к хранилищу подписывающих активов.
- Ключ расшифровки позволяет получить содержимое защищённого хранилища, если оно зашифровано.
- Сертификат и закрытый ключ образуют используемую для подписи личность; сертификат без доступного соответствующего ключа недостаточен. Apple описывает роль сертификатов в документации о сертификатах командной подписи и в техническом разборе сертификатов кодовой подписи.
- iOS Provisioning Profile должен подходить приложению и назначению сборки.
- Параметры Xcode определяют, какие активы используются для конкретного target и конфигурации.
- Archive, экспорт IPA и загрузка — отдельные этапы; прохождение одного не подтверждает прохождение остальных.
Такое разделение предотвращает распространённую ошибку диагностики: удаление или пересоздание сертификатов до выяснения, действительно ли проблема находится в сертификате. Сначала нужно определить точную точку отказа, а затем менять только тот компонент, который не соответствует задаче.
Первый запуск на новом удалённом Mac
На новой машине match может синхронизировать сертификаты и профили, но задача Xcode всё равно должна работать в совместимом окружении. Сверьте пользователя, от имени которого запускается fastlane, с пользователем, которому доступна нужная связка ключей. Убедитесь, что задача обращается к ожидаемой копии проекта и получает те же параметры среды, что и проверенный локальный запуск.
Не ограничивайтесь сообщением о завершении синхронизации. Сохраните безопасную диагностическую запись о запуске: она поможет понять, использовались ли нужный проект и конфигурация, не раскрывая секреты. Не включайте в логи пароль хранилища, закрытый ключ, содержимое сертификата в виде приватных данных, токены или учётные данные репозитория.
Для разбора миграции заведите такую карточку запуска. Это шаблон для заполнения, а не пример реального успешного лога:
Проект и схема: <название без секретов>
Target и конфигурация: <значения из задания>
Пользователь процесса: <учётная запись задачи>
Источник match: <доступ подтверждён / ошибка доступа>
Расшифровка хранилища: <доступна / ошибка>
Синхронизация профиля: <результат>
Подписывающая личность: <доступна / отсутствует>
Этап сбоя: <сборка / Archive / экспорт IPA / загрузка>
Указывайте только те сведения, которые нужны для диагностики. Не публикуйте заполненную карточку с путями, внутренними идентификаторами или подробностями окружения, если они могут раскрыть конфигурацию команды.
Документация fastlane отдельно рассматривает синхронизацию на новой машине и рекомендует readonly для CI-процесса (условия работы match и readonly). Это не означает, что любой новый Mac автоматически готов к подписи: после получения файлов необходимо подтвердить, что их может использовать именно текущая задача. Если вы переносите постоянные сборки, сначала зафиксируйте проверенное окружение, а затем сравнивайте с ним результат нового запуска.
Сертификат найден, но закрытый ключ не используется
В связке ключей может присутствовать сертификат, однако нужная задача не видит закрытый ключ, который ему соответствует. Это разные состояния: запись о сертификате ещё не доказывает, что доступна целостная подписывающая личность. Apple объясняет, что сертификаты командной подписи связаны с ключами, используемыми для подписи, а сведения о сертификатах и ключах относятся к работе с кодовой подписью (техническое описание Apple).
Проверяйте эту часть в контексте фактического пользователя сборки. Если разработчик вошёл в графическую сессию под одной учётной записью, а фоновый агент выполняется под другой, у них может быть разный доступ к ключам. Поэтому проверка из ручного сеанса не заменяет проверку в задаче fastlane. Уточните, какую связку ключей использует процесс, и есть ли в ней доступная пара сертификат–ключ, соответствующая ожидаемому подписанию.
Не следует наугад отзывать сертификат, сбрасывать связки или создавать новую пару ключей. Это способно повлиять на другие сборки и участников команды, не исправив первоначальную причину — например, несовпадение учётной записи или отсутствие доступа к сохранённому ключу. Сначала сохраните относящееся к ошибке сообщение, установите пользователя и источник ключа, затем согласуйте восстановление доступа с тем, кто отвечает за общий процесс подписи.
Профиль установлен, но проект выбирает другую подпись
Успешная установка iOS Provisioning Profile не гарантирует, что он выбран для Archive. Сверьте идентификатор приложения, target, конфигурацию сборки и назначение профиля с фактической задачей. Настройки проекта могут задавать подпись отдельно для разных конфигураций, а в одном проекте может быть несколько целей, каждая из которых нуждается в своём соответствии между приложением, профилем и сертификатом.
Apple описывает профили подготовки как часть процесса подписи и распространения приложения; для распространения через App Store профиль имеет конкретное назначение (создание профиля App Store). Параметры подписи задаются в настройках сборки Xcode, поэтому полезно сопоставлять не только имя установленного файла, но и настройки, реально применённые к целевому target (справочник настроек сборки Xcode).
Проверяйте расхождения в таком порядке:
- Убедитесь, что анализируете target приложения, а не тестовую или вспомогательную цель.
- Сопоставьте Bundle ID с тем приложением, для которого подготовлен профиль.
- Проверьте конфигурацию, выбранную для Archive, а не только Debug-запуск.
- Уточните, соответствует ли профиль целевому способу распространения.
- Сравните выбранные Xcode параметры подписи с ожидаемой парой сертификат–профиль.
Если система автоматически управляет подписью, не предполагайте, что она выберет именно тот профиль, который вы заметили среди синхронизированных файлов. Сопоставьте результат Archive и фактические параметры проекта. Apple отдельно описывает кодовую подпись приложения как механизм, связывающий подписывающие данные и приложение (обзор подписи приложений). Это полезная граница: установленный профиль — входной актив, а не подтверждение, что итоговая сборка использовала его.
Выбор режима для миграции, CI и публикации
Путь диагностики зависит от того, какую задачу выполняет удалённый Mac. При первичной подготовке нужно проверить доступ и наличие активов; в регулярной сборке — получать уже утверждённые активы, не изменяя общее хранилище; при выпуске — подтвердить результат именно через Archive и нужное назначение распространения.
| Сценарий | Что проверить | Подход к match | Критерий перехода дальше |
|---|---|---|---|
| Первичный запуск на новом удалённом Mac | Пользователь задачи, доступ к хранилищу, расшифровку и доступность закрытого ключа | Сначала подтвердить доступ и синхронизацию; изменение активов — только при установленной необходимости | Подписывающая личность доступна задаче, профиль подходит target |
| Регулярный CI | Доступ к утверждённым активам и их расшифровке, одинаковые параметры проекта | Использовать readonly, если нужные активы уже созданы и доступны |
Сборка использует ожидаемую подпись без обновления общего набора |
| Подготовка публикации | Назначение профиля, конфигурацию Archive и результат архивирования | Сохранять штатную стратегию синхронизации; режим сам по себе не исправляет настройки | Archive проверен для целевого способа распространения |
readonly предназначен для синхронизации существующих подписывающих активов в CI, а не для автоматического исправления их несоответствия. Если задание не может прочитать репозиторий, сначала исправляют доступ. Если хранилище прочитано, но не расшифровано, отдельно проверяют безопасную передачу необходимого секрета. Если оба этапа завершились, а Xcode не подписывает приложение, переходят к связке ключей, профилю и конфигурации.
Не передавайте ключ расшифровки или учётные данные в открытом логе. Проверяйте сам факт доступности секрета через механизм управления секретами, принятый в проекте, а не выводите его значение для удобства диагностики.
Для CI полезно также вести разделение прав: задача должна иметь достаточно доступа для чтения разрешённых активов, но диагностике не требуется раскрытие содержимого ключей. Описание match охватывает хранение и синхронизацию активов; способ передачи секретов в конкретной инфраструктуре следует согласовать отдельно, не подменяя его предположением, что режим readonly решает вопросы безопасности.
Частые вопросы о fastlane match и удалённой подписи
Синхронизация завершилась, но идентификатор подписи не найден
Причина часто находится не в репозитории match, а в доступности закрытого ключа для пользователя процесса. Проверьте, кто запускает задачу, и доступна ли этому пользователю соответствующая связка ключей. Затем убедитесь, что проверяется нужная подписывающая личность, а не только установленный сертификат. Если ключ отсутствует, сначала выясните, где находится утверждённый источник, вместо того чтобы немедленно отзывать сертификат.
Закрытый ключ отсутствует в связке ключей входа
Не переносите ключ или связку между пользователями без согласованной процедуры. Сначала определите, какой пользователь выполняет задачу и какие связки ключей он действительно может использовать. Дальше восстановите доступ к одобренному ключу способом, принятым командой, или согласуйте обновление подписывающих активов. После этого проверьте результат из того же контекста, в котором запускается удалённый CI.
Можно ли оставить readonly для публикационной сборки
Можно, если CI получает уже подготовленные активы, может прочитать репозиторий и расшифровать хранилище, а настройки проекта соответствуют выбранному профилю. readonly не создаёт отсутствующий сертификат и не меняет профиль для другого назначения. Поэтому публикационный запуск необходимо проверять через Archive и последующий этап распространения, а не считать успешной синхронизацию доказательством готовности релиза.
Локально подпись работает, а удалённый Archive падает
Начните с различий между исполнениями: пользователь задачи, доступ к закрытому ключу, источник секретов, параметры схемы и конфигурация Archive. Затем установите, где именно остановился процесс. Успех обычной сборки или локального Debug-запуска не подтверждает успешность Archive, экспорта IPA и загрузки: это отдельные этапы, которые следует анализировать по соответствующим журналам.
Проверка Archive как критерий восстановления
После исправления причины повторите задачу с тем же проектом, target, конфигурацией и назначением распространения, для которых возникла ошибка. Цель — не просто получить зелёный статус сборки, а проверить, что удалённый Mac сформировал Archive с ожидаемой подписью. Apple описывает архивирование, распространение и экспорт приложения как этапы процесса доставки (справка о распространении приложения из Xcode).
Сверьте относящиеся к результату сведения: идентификатор приложения, выбранную подписывающую личность, применённый профиль и назначение архива. Не делайте вывод о восстановлении публикации только по успешному компилированию. Если процесс включает экспорт IPA и загрузку, проверяйте их отдельно: ошибка после Archive может относиться уже к экспортной конфигурации или следующему этапу, а не к первоначальной проблеме подписи.
Для повторяемости сохраните безопасную запись о пользователе задачи, версии инструментов, способе получения активов и проверенном результате. Версии и параметры нужно фиксировать из реального запуска, а не подставлять ожидаемые значения. Проверка подтверждает только конкретный проект, конфигурацию и способ распространения; она не доказывает автоматически, что другая цель или другой продукт подписываются тем же образом.
Если после синхронизации остаётся неясно, что именно выполняется на удалённом Mac, полезно сначала сверить доступные способы подключения и работу среды в описании удалённого Mac. При вопросах о порядке доступа и эксплуатации можно обратиться к справочному центру. Эти сведения помогают оценить рабочее окружение, но не заменяют проверку подписывающих активов и настроек конкретного проекта.
Когда удалённый Mac оправдан для подписи
Если сборка остаётся на рабочем компьютере, ресурсы разработки и публикации конкурируют за одну машину, результат зависит от локального состояния, а передача задач другим участникам требует повторять настройки окружения. Отдельная удалённая среда может быть удобнее для изолированного Archive и постоянного CI-процесса, если разработчику нужен именно доступ к macOS-сборке без покупки и обслуживания отдельного Mac. Просмотрите описание NodeMini, прежде чем переносить задачу, и сверяйте доступные условия с реальными требованиями проекта.
Аренда не является универсальной заменой собственной машине: для постоянной тяжёлой нагрузки, локальной периферии или сценариев, требующих физического подключения устройств, собственное оборудование может оказаться подходящим выбором. Если же сбой вызван лишь неправильной связкой ключей, профилем или параметрами Xcode, смена среды его не исправит. Сначала подтвердите причину на настоящем Archive; затем выбирайте между локальным Mac и удалённой средой по тому, где удобнее безопасно хранить доступ к активам и регулярно выполнять публикационные задачи.