Xcode 26 установлен, но CI сообщает «лицензия не принята»? Сначала зафиксируйте фактический путь к Xcode, затем по локальной документации этой версии выполните проверку лицензии и first-launch, а после этого повторите минимальную сборку от имени реального сервисного аккаунта. Только успешная проверка в том же контексте, где работает агент, является основанием для массового исправления.
Этот материал предназначен для IT-руководителей, которым нужно унифицировать поставку Xcode на локальных или удалённых Mac. Он также пригодится владельцам платформ, устраняющим сбой в неинтерактивной среде CI, и техническим руководителям, оценивающим влияние инициализации на выпуск, резервные узлы и SLA команды.
SECTION 01Диагностическая граница для Xcode 26
Противоречие «администратор в Terminal собирает, а CI всё ещё говорит, что лицензия не принята» обычно означает не отсутствие Xcode как такового. В разных контекстах могут использоваться разные каталоги разработчика, переменные окружения, пользователи и состояния локальной инициализации.
До любых изменений зафиксируйте четыре свидетельства:
- какой исполняемый файл вызывается;
- какой каталог разработчика выбран;
- какой аккаунт запускает агент;
- какой именно этап останавливается — лицензия, first-launch, компонент, подпись или проект.
Проверка версии не доказывает, что последующая команда использует тот же путь. Поэтому путь и версию нужно записывать в одном сеансе и в том же окружении, где будет выполняться сборка.
xcode-select -p
xcodebuild -version
command -v xcodebuild
Если на узле установлено несколько копий Xcode, проверьте также путь приложения, назначенный для конкретного задания. Для этого используйте переменную DEVELOPER_DIR на уровне одной задачи, а не меняйте глобальное состояние машины без необходимости:
DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer" xcodebuild -version
Путь в примере является шаблоном. В вашем образе он должен соответствовать реально установленной версии. Нельзя считать, что наличие каталога /Applications/Xcode.app автоматически означает использование именно этого инструментария.
Официальные сведения о настройке Command Line Tools и выборе каталога разработки собраны в документации Apple по установке Command Line Tools. Там же важно отделять системный выбор инструментов от выбора, который задаётся конкретной задачей CI.
| Наблюдение в журнале | Что это может означать | Кто подтверждает | Следующее действие |
|---|---|---|---|
| Указан другой путь Xcode | Агент использует другую установку или системный выбор | Владелец платформы | Зафиксировать DEVELOPER_DIR или исправить выбор инструментов |
| Лицензия запрашивается до запуска сборки | Локальная лицензия не обработана в текущей установке | Команда поставки Mac | Сверить локальную справку xcodebuild и выполнить разрешённую процедуру |
| Требуется first-launch | Не завершены первоначальные задачи конкретной версии | Администратор узла | Выполнить и проверить инициализацию с нужными полномочиями |
| Отсутствует компонент или SDK | Установка неполная либо задача требует дополнительного компонента | Владелец Xcode-образа | Сверить документацию версии и установить только нужный компонент |
| Лицензия пройдена, но подпись не удалась | Проблема относится к Keychain, профилю или сертификату | Команда релиза и безопасности | Перейти к отдельной диагностике подписи |
| Минимальная сборка проходит, проект падает | Причина находится в зависимостях, настройках или коде проекта | Команда разработки | Не менять состояние лицензии, анализировать проект |
Что означает сообщение о лицензии
Фраза Xcode 26 license agreement required указывает на необходимость обработать лицензионное состояние используемой установки, но не объясняет, почему именно проверка не пройдена. Причиной может быть другая копия Xcode, другой пользователь или запуск в чистом неинтерактивном окружении.
Лицензия программного обеспечения, локальная задача first-launch и онлайн-соглашение Apple Developer Program — разные объекты контроля. Принятие одного из них не подтверждает автоматически остальные. В частности, успешная локальная инициализация не выдаёт права на подпись приложения, а наличие прав разработчика не заменяет локальную обработку лицензии.
Параметры и коды возврата нельзя переносить из старого runbook без проверки. Откройте справку той копии, которая действительно будет использоваться:
DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer" xcodebuild --help
DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer" man xcodebuild
Если в справке этой версии присутствуют параметры для принятия лицензии или запуска first-launch, используйте именно их синтаксис. Перед массовым применением сохраните вывод команды и код возврата. Не подменяйте проверку документации универсальной командой, скопированной из статьи для другой версии.
Сведения о совместимости, изменениях и известных требованиях нужно сверять с официальными заметками к выпуску Xcode 26. Это особенно важно, если один пул машин содержит разные малые версии Xcode.
SECTION 02Распределение ответственности между ролями
Массовое исправление ломается не из-за отсутствия одной команды, а из-за неясной передачи доказательств. У каждой роли должны быть собственные условия завершения и право остановить развёртывание.
IT и команда поставки Mac
Вы отвечаете за воспроизводимое состояние узла, а не за ручной запуск графического интерфейса. В базовой записи должны присутствовать:
- путь к приложению Xcode;
- вывод версии;
- выбранный каталог разработчика;
- пользователь и группа, под которыми работает агент;
- результат локальной проверки лицензии;
- результат first-launch;
- список фактически установленных компонентов;
- время и идентификатор узла;
- код возврата каждой критичной операции.
Если для инициализации требуются права администратора, выдавайте их только конкретной команде и на конкретном этапе. Не передавайте общий пароль администратора в скрипт или журнал. Секреты, сертификаты и ключи подписи не должны появляться в процессе только потому, что вы готовите машину к CI.
Передача узла платформенной команде возможна только после того, как путь и состояние Xcode подтверждены. Устное сообщение «Xcode установлен» для этой цели недостаточно.
Владелец CI-платформы
Сервисный аккаунт должен проверяться отдельно от административного пользователя. У него могут отличаться:
- домашний каталог;
- переменные окружения;
- доступ к Keychain;
- рабочий каталог;
- оболочка;
- права на временные файлы;
- способ запуска агента;
- доступ к выбранному Xcode.
Если администратор успешно выполняет xcodebuild, это не доказывает, что тот же результат будет у агента. Запустите диагностический этап от имени производственного аккаунта и сохраните его окружение без вывода секретов:
id
pwd
xcode-select -p
xcodebuild -version
Для конкретной задачи задайте DEVELOPER_DIR явно, если на машине сосуществуют несколько версий. Глобальный xcode-select удобен как базовое состояние узла, но он не должен быть единственным механизмом выбора инструментария в параллельных или поэтапных заданиях.
Команда безопасности
Вам необходимо разделить право на изменение узла и право на использование ключей подписи. Инициализация Xcode не должна автоматически:
- импортировать долгоживущие сертификаты;
- добавлять личный Apple-аккаунт;
- раскрывать пароль Keychain;
- включать удалённый доступ шире утверждённой политики;
- выдавать сервисному аккаунту права администратора без срока и ограничения.
Состояние Keychain проверяйте отдельным этапом. Документация Apple по управлению секретами в Keychain помогает отделить хранение секретов от локальной инициализации Xcode. Если лицензия принята, но подпись не работает, не повторяйте процедуру лицензирования: передайте сбой команде безопасности и владельцу релиза.
Релизная команда
Ваша задача — подтвердить, что узел готов не только ответить на xcodebuild -version, но и выполнить минимальный путь поставки. Проверяйте слои последовательно:
- версия и путь;
- минимальная сборка без подписи;
- разрешение зависимостей;
- сборка настоящего проекта;
- тесты;
- архив;
- подпись и экспорт, если они входят в назначение узла.
Сведения о базовом процессе сборки и запуска можно сопоставить с официальным руководством Apple по сборке приложения. Команда релиза не должна объявлять проблему лицензии исправленной только потому, что административный Terminal больше не показывает предупреждение.
SECTION 03Повторяемая инициализация и массовая поставка
Как исправить сбой CI из-за требования принять лицензию Xcode 26? Сначала определите копию Xcode и контекст аккаунта, затем прочитайте xcodebuild --help и man xcodebuild именно из этого каталога. После выполнения документированной процедуры лицензии проверьте first-launch, версию и минимальную сборку от имени CI-аккаунта. Если любой слой использует другой путь или пользователя, исправление ещё не подтверждено.
В скрипте поставки полезно разделять этапы, чтобы ошибка не маскировалась общей строкой «инициализация завершена»:
set -u
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
xcode-select -p
xcodebuild -version
# Команду лицензирования и first-launch подставляйте
# только после проверки локальной справки этой версии.
xcodebuild --help
man xcodebuild
# Затем — минимальная проверка, определённая вашим проектом.
Это не готовый универсальный скрипт массового принятия лицензии. Его задача — показать границы автоматизации. Конкретные параметры, требуемые полномочия и коды возврата должны быть зафиксированы на изолированном узле с установленным Xcode 26. Такой подход предотвращает ситуацию, когда скрипт формально завершился, но состояние инструментария не изменилось.
Чем xcodebuild -runFirstLaunch отличается от принятия лицензии? Это разные операции: первая относится к первоначальным задачам и подготовке локальной среды, а вторая — к лицензионному состоянию. Их нельзя считать взаимозаменяемыми. Название параметра и его поведение нужно проверять в справке установленной малой версии, поскольку нельзя переносить предположения о флагах между выпусками.
Для массовой инициализации используйте следующую модель:
- Сформируйте список узлов и назначенную им версию Xcode.
- Проверьте путь приложения, каталог разработчика и наличие нужных компонентов.
- Выберите пилотную машину, изолированную от производственной очереди.
- Выполните лицензирование и first-launch согласно локальной справке.
- Запишите пользователя, полномочия, код возврата и полный безопасный вывод.
- Запустите минимальную сборку от имени сервисного аккаунта.
- Повторите проверку после нового сеанса CI.
- Перезагрузите пилотный узел и повторите ключевые проверки.
- Сравните результаты с эталонной записью.
- Только после этого переносите процедуру на следующую группу машин.
Для подтверждения минимальной сборки можно использовать заранее подготовленный тестовый проект без подписи. Команды и параметры должны соответствовать вашему проекту и версии Xcode; нельзя считать, что наличие одного SDK подтверждает готовность всех платформенных компонентов. Если проект использует дополнительные компоненты, их состояние проверяется отдельно по документации Apple по установке компонентов Xcode.
SECTION 04Приёмка сервисного аккаунта
Почему CI-аккаунт всё ещё получает сообщение о непринятой лицензии после успешной проверки администратором? Потому что лицензия или first-launch могли быть обработаны в другом пользовательском контексте, а агент обращается к другой копии Xcode или другому каталогу. Повторите проверку без GUI, тем же способом запуска и с теми же переменными, которые используются производственным заданием.
Не смешивайте в одном тесте все возможные причины. Последовательность должна позволять определить точку возврата:
- Если не совпадает путь — верните узел владельцу поставки Mac.
- Если путь совпадает, но лицензия не обработана — верните узел на локальную инициализацию.
- Если лицензия обработана, но first-launch не завершён — повторите только этот этап после проверки полномочий.
- Если минимальная сборка не запускается — проверьте SDK, компоненты и рабочий каталог.
- Если минимальная сборка проходит, а подпись не работает — передайте случай владельцу Keychain и релизной команде.
- Если ручной запуск проходит, а агент падает — исследуйте контекст запуска и окружение runner.
Не используйте реальный секрет подписи для доказательства того, что лицензия принята. Сначала добейтесь успешной неподписанной минимальной сборки, затем переходите к зависимостям, архивированию и подписи. Такой порядок уменьшает область поиска и не раскрывает ключи во время диагностики.
SECTION 05Серый запуск и условия расширения пула
Перед массовым изменением узлов запишите исходное состояние очереди: какие машины принимают задания, какие находятся в резерве, где размещаются проекты и какой узел можно вывести из эксплуатации без остановки выпуска. Фактические сроки восстановления, пропускная способность и время инициализации должны основываться на ваших журналах или измерениях, а не на типовом обещании поставщика.
Используйте чек-лист перед расширением:
- [ ] На пилотном узле подтверждены путь, версия и каталог разработчика.
- [ ] Лицензия обработана согласно справке установленной версии.
- [ ] First-launch завершён, а код возврата сохранён.
- [ ] Минимальная сборка выполнена от имени производственного сервисного аккаунта.
- [ ] Настоящий проект собран без подписи.
- [ ] Зависимости разрешены в том же окружении.
- [ ] Тесты и архив проверены согласно назначению узла.
- [ ] Подпись проверена отдельно, без изменения процедуры лицензирования.
- [ ] После нового сеанса CI результат повторён.
- [ ] После перезагрузки узла ключевые проверки снова успешны.
- [ ] Есть рабочая процедура возврата к прежнему Xcode.
- [ ] Производственная очередь не зависит от единственного пилотного узла.
- [ ] Аудит содержит исполнителя, время, версию, узел и коды возврата.
- [ ] В журнал не попали пароли, личные аккаунты и секреты подписи.
Пилот считается успешным только тогда, когда новый сеанс CI и перезагрузка не меняют результат. Если после перезапуска лицензия снова запрашивается, ищите зависимость от интерактивной сессии, временного окружения или пользовательского Keychain. Такой узел нельзя отправлять в общий пул.
SECTION 06Решение по существующим и удалённым Mac
Если имеющиеся Mac можно изолировать, снабдить резервной копией конфигурации и быстро вернуть в прежнее состояние, продолжайте поэтапное исправление существующего пула. Если же любое изменение затрагивает единственную производственную машину, а восстановление зависит от ручной работы, сначала создайте независимый пилотный узел.
В этой точке удалённый Mac полезен не как способ скрыть проблему, а как отдельная граница эксперимента. Вы можете проверить установку Xcode 26, путь инструментария, сервисный аккаунт, перезагрузку и реальную задачу CI, не выводя основной узел из очереди. Для предварительной оценки доступных вариантов можно изучить условия аренды удалённого Mac в MACNOX, а параметры заказа проверить на странице заказа MACNOX.
У текущей схемы с локальными Mac есть несколько реальных ограничений: узел может быть физически занят разработчиком, обновление может временно остановить очередь, а восстановление после неудачной инициализации часто требует ручного доступа к машине. Добавление независимого удалённого Mac не отменяет требования безопасности и аудита, но позволяет провести Xcode 26 инициализацию в отдельном контуре, не смешивая её с рабочим состоянием.
Аренда не является лучшим вариантом для постоянной тяжёлой нагрузки, требований к физическим интерфейсам или длительной эксплуатации полностью контролируемого собственного оборудования. Но для пилота, временного пула, проверки новой версии Xcode и резервной CI-мощности она может быть рациональнее, чем рискованное изменение единственного производственного узла. Решение принимайте по доказательствам: изоляция, повторяемость, восстановление после перезагрузки и успешный запуск реального задания.
Если вам нужно исправить «лицензия Xcode 26 не принята» на нескольких машинах, не начинайте с повторной установки. Зафиксируйте путь, проверьте локальную справку, выполните лицензирование и first-launch в правильном контексте, затем подтвердите результат сервисным аккаунтом. Когда существующий пул нельзя безопасно остановить, независимый удалённый Mac от MACNOX даёт место для серой инициализации и реальной проверки iOS CI/CD без немедленного риска для основной очереди.