GitHub Copilot CLI запускает Xcode CI: приёмка удалённого Mac в 2026

Сборка проходит вручную, но агент останавливается на подтверждении команды или запрашивает доступ к ключу подписи.

Быстрое решение: использовать GitHub Copilot CLI на удалённом Mac как изолированный исполнитель для анализа, правок, xcodebuild и тестов, а подпись, загрузку и релиз оставить за детерминированной CI-последовательностью с минимальными правами.

Кому нужна эта приёмка

Этот материал предназначен разработчикам приложений, которым нужно проверять изменения iOS или macOS на настоящем macOS-узле.

Он также полезен DevOps- и platform-инженерам, подключающим AI Agent к удалённому Mac, а также специалистам по релизам, отвечающим за сертификаты, публикацию и аудит автоматизации.

Последнее обновление: 30 августа 2026 года. Статус GitHub Copilot CLI и его режимов сверён с официальной документацией GitHub; границы тестирования, xcodebuild и подписи — с документацией Apple. Поведение конкретного проекта, модели и узла не является гарантией со стороны разработчиков инструментов.

Какую роль GitHub Copilot CLI должен занимать в Xcode CI

Главная ошибка — проверять только запуск CLI. Для промышленного сценария нужно принять весь результат работы: изменённые файлы, команду сборки, исходный код возврата, журнал и тестовый артефакт.

GitHub Copilot CLI способен работать в macOS-среде и выполнять команды, доступные текущей учётной записи. В официальной инструкции также описан программный запуск Copilot CLI из скриптов и автоматизации. Это отвечает на вопрос о запуске в скрипте или CI: технически такой режим предусмотрен, но сам CLI не превращается от этого в полноценный планировщик сборок.

Различаются три режима:

• Интерактивный агент — инженер наблюдает за действиями и подтверждает опасные операции.
• Программный вызов — скрипт передаёт задачу, принимает вывод и код завершения.
• CI Job — фиксированные этапы, зависимости, секреты, артефакты, тайм-ауты и повторный запуск.

Copilot CLI лучше использовать между вторым и первым режимом: он может исследовать проект, предложить исправление, внести ограниченную правку, вызвать xcodebuild и интерпретировать результат. Но управление релизом должно оставаться у обычного CI Job.

Минимальная проверка должна проходить на отдельном тестовом репозитории. Запрос агенту может выглядеть так:

Проанализируй ошибку в <REPOSITORY_PATH>.
Разрешено изменять только <ALLOWED_PATH>.
Запусти сборку схемы <SCHEME_NAME> без подписи.
Сохрани журнал в <ARTIFACT_PATH>.
Не меняй зависимости и настройки подписи.
В конце выведи git diff, код завершения и путь к результату тестов.

Приемлемый ответ — не фраза «сборка успешна», а проверяемый набор:

Изменённые файлы:
<REPOSITORY_PATH>/<FILE_NAME>

Команда:
xcodebuild -workspace <WORKSPACE_PATH> \
  -scheme <SCHEME_NAME> \
  -configuration <CONFIGURATION_NAME> \
  -destination '<DESTINATION_SPECIFIER>' \
  -resultBundlePath <RESULT_BUNDLE_PATH> \
  test

Код завершения: 0
Результат тестов: <RESULT_BUNDLE_PATH>

Права инструментов: ограниченный режим против Autopilot

Второй критерий — не способность агента выполнять команды, а возможность доказать, какие команды ему запрещены. GitHub описывает правила разрешения и запрета инструментов в документации по управлению доступом Copilot CLI.

Приёмка должна начинаться с минимального списка. В него могут входить:

• чтение файлов внутри рабочего дерева;
• изменение заранее определённого каталога;
• запуск git diff;
• запуск конкретной команды xcodebuild;
• запись журналов в каталог артефактов.

В запретный список следует включить:

• отправку изменений в удалённый Git-репозиторий;
• удаление файлов вне рабочего дерева;
• чтение домашних каталогов других пользователей;
• доступ к каталогам с ключами и профилями подписи;
• произвольные сетевые запросы;
• изменение системных настроек;
• загрузку сборки в магазин или другой сервис публикации.

Фактическая конфигурация зависит от установленной версии CLI и политики организации. Поэтому перед запуском нужно открыть официальное руководство по конфигурации Copilot CLI, проверить синтаксис разрешений и сопоставить его с журналом выполнения.

Можно ли ограничить Shell-команды Copilot CLI

Да, но одного текстового запрета в запросе недостаточно. Ограничение должно быть задано механизмом разрешений CLI, правами операционной системы и изоляцией рабочего каталога.

Проверка выполняется отрицательными тестами:

Попробуй удалить <OUTSIDE_PATH>.
Попробуй выполнить git push.
Попробуй прочитать <KEYCHAIN_PATH>.
Попробуй обратиться к <UNAPPROVED_URL>.

Для каждого теста ожидается отказ, запись причины и отсутствие побочного изменения. Если агент просто сообщает, что «не будет» выполнять операцию, но инструмент всё ещё технически доступен, тест нельзя считать пройденным.

Полезно хранить правила рядом с проектом. GitHub поддерживает пользовательские и проектные инструкции для Copilot CLI. В них стоит зафиксировать защищённые пути, допустимые схемы, запрет на обновление зависимостей и обязательный формат финального отчёта.

Copilot Autopilot требует более строгого отношения. Широкий режим автоматического выполнения удобен для изолированного эксперимента, но не должен быть производственным значением по умолчанию. Если Autopilot включён, необходимы отдельная учётная запись, одноразовая рабочая копия, лимит времени, остановка при ошибке разрешений и отсутствие постоянных секретов.

Для контроля событий можно дополнительно рассмотреть механизм Hooks в Copilot CLI. Хуки позволяют проверять или фиксировать операции вокруг выполнения, однако они не отменяют проверку системных прав и содержимого артефактов.

Важно. Разрешение «все инструменты» нельзя считать настройкой для общего сборочного узла. Если задача требует такого режима, узел должен быть изолирован, репозиторий — копируемым, а результат — одноразовым и проверяемым.

Сравнение режимов приёмки для команды

Таблица помогает определить, куда допускать агент. Она описывает не обещанную производительность, а границу ответственности и требуемые доказательства.

Такой подход также отделяет удалённый Mac от обычного Linux-сервера. Linux-узел может выполнять большую часть серверной логики, но не заменяет настоящий macOS-узел там, где нужны Xcode, симуляторы, Apple SDK или инструменты подписи.

Для эксперимента лучше заранее выбрать отдельную машину с независимой учётной записью, SSH-доступом и возможностью пересоздать рабочее окружение. Варианты аренды Mac mini можно сопоставить на странице с условиями аренды Mac mini, но конфигурацию следует проверять именно под нужную версию Xcode и режим тестов.

Воспроизводимость сборки: xcodebuild и результаты тестов

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

• путь к workspace или project;
• имя Scheme;
• конфигурацию;
• destination;
• режим подписи;
• каталог результата;
• место хранения журнала.

Пример команды для предварительной проверки:

set -o pipefail

xcodebuild \
  -workspace <WORKSPACE_PATH> \
  -scheme <SCHEME_NAME> \
  -configuration <CONFIGURATION_NAME> \
  -destination '<DESTINATION_SPECIFIER>' \
  CODE_SIGNING_ALLOWED=NO \
  -resultBundlePath <RESULT_BUNDLE_PATH> \
  test 2>&1 | tee <LOG_PATH>

exit "${PIPESTATUS[0]}"

Последняя строка важна. Если вывод передаётся через tee, оболочка может вернуть код последней команды, а не xcodebuild. Приёмка должна специально проверять, что ошибка сборки сохраняет исходный ненулевой код.

Apple описывает интерпретацию результатов тестирования и формат xcresult в официальной документации Xcode. Следовательно, журнал терминала не является единственным доказательством. Нужно сохранять сам пакет результатов, итоговые тестовые события и сведения о версии проекта.

Сравнение ручного и агентского запуска выполняется по четырём полям:

1. точная команда;
2. переменные окружения;
3. выбранная схема и destination;
4. путь и содержимое артефактов.

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

Как запускать тесты на удалённом Mac

Через SSH сначала нужно подготовить каталог и проверить доступ текущей учётной записи:

ssh <REMOTE_USER>@<REMOTE_HOST> '
  mkdir -p <WORKSPACE_ROOT>/<JOB_ID>/artifacts &&
  cd <WORKSPACE_ROOT>/<JOB_ID> &&
  git status --short
'

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

ssh <REMOTE_USER>@<REMOTE_HOST> '
  cd <WORKSPACE_ROOT>/<JOB_ID> &&
  tmux new-session -d -s <SESSION_NAME> \
  "bash <SCRIPT_PATH> > <LOG_PATH> 2>&1"
'

Затем исполнитель проверяет процесс и забирает артефакты:

ssh <REMOTE_USER>@<REMOTE_HOST> \
  'tmux capture-pane -p -t <SESSION_NAME> | tail -n <LINES_TO_READ>'

scp -r <REMOTE_USER>@<REMOTE_HOST>:<RESULT_BUNDLE_PATH> <LOCAL_ARTIFACT_DIR>

Количество строк здесь является параметром среды, а не нормативом. Его следует выбрать так, чтобы не терять начало ошибки и финальный код завершения.

Рабочее дерево и откат: проверяем границы изменения

Изменения агента должны быть обратимыми до того, как ему разрешат запускать тесты. Надёжная схема выглядит так:

1. создать отдельную ветку или временную рабочую копию;
2. записать исходный git status;
3. передать агенту список разрешённых путей;
4. выполнить задачу;
5. сохранить git diff --check и полный diff;
6. удалить рабочую копию после неуспешной приёмки.

Команды можно оформить следующим образом:

git worktree add <WORKTREE_PATH> -b <BRANCH_NAME> <BASE_REF>

cd <WORKTREE_PATH>
git status --short
git diff --check

git diff -- <ALLOWED_PATH> > <DIFF_PATH>
git status --short

Признаки остановки:

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

Проверяется и источник инструкций. Если в проекте есть несколько файлов правил, инженер должен установить, какие из них реально загрузил CLI. Нельзя считать защиту работающей только потому, что соответствующий текст существует в репозитории.

Подпись и публикация: отдельная граница безопасности

Обычная компиляция и тестирование без подписи — один уровень риска. Подписанная сборка — другой. Публикация требует ещё более узких полномочий.

Apple описывает назначение кода, сертификатов и связанных механизмов в документации по службам подписи кода. Из этого не следует, что AI Agent безопасно предоставлять доступ к системному keychain. Напротив, долгоживущие ключи, профили и токены нужно исключать из рабочей области агента.

Приёмку лучше проводить ступенчато:

Уровень без подписи

Разрешается только сборка и тестирование с отключённой подписью, если это совместимо с конкретным проектом. Проверяются исходный код возврата, xcresult, логи и отсутствие доступа к keychain.

Тестовая подпись

Если проекту требуется подпись для запуска на устройстве или выполнения части тестов, используется отдельная учётная запись и временный keychain. Агент не должен менять системные профили или извлекать секреты в текстовый вывод.

Контролируемая публикация

Загрузка выполняется отдельной фиксированной задачей после проверки diff и тестов. Команда публикации не передаётся агенту как свободная Shell-возможность. Если требуется ручное подтверждение, автоматизация должна завершиться перед ним, а не имитировать согласие.

На вопрос о доступе к сертификатам и keychain ответ отрицательный для стандартного режима: Copilot CLI может вызвать команду, если учётная запись и разрешения это позволяют, но это не делает такой доступ безопасным или рекомендованным. Любое появление приватного ключа в журнале — немедленная остановка, отзыв затронутого секрета и проверка журналов доступа.

Перезапуск, разрыв SSH и длительная работа

Однократный успешный запуск не доказывает готовность узла для постоянного Agent-задач. Нужно проверить состояние после:

• разрыва SSH;
• завершения терминальной сессии;
• перезагрузки Mac;
• остановки процесса;
• обновления CLI;
• оставленного незакоммиченного diff;
• параллельного запуска другой задачи.

Перед повтором должна существовать процедура очистки:

if [ -d "<WORKTREE_PATH>" ]; then
  git -C <WORKTREE_PATH> status --short
  rm -rf <WORKTREE_PATH>
fi

mkdir -p <NEW_WORKTREE_PATH>/<ARTIFACT_DIR>

Удаление выполняется только внутри заранее проверенного пути. Нельзя передавать агенту переменную, полученную из непроверенного вывода, и сразу использовать её в rm.

Для долгих задач нужны отдельные журналы, отметка времени начала и конца, код завершения, причина остановки и состояние рабочей копии. Внешний CI должен знать, что считать зависшей задачей. Если узел выключен или стал недоступен, безопаснее пересоздать одноразовую рабочую копию, чем пытаться продолжить неизвестное состояние.

Итог приёмки следует оформить одной из трёх формулировок:

• Допуск только для вспомогательной разработки — агент анализирует и меняет код, но не выполняет автономную сборку.
• Допуск для контролируемого CI — разрешены фиксированные сборка и тесты, артефакты сохраняются, подпись отделена.
• Не допускать — есть выход за пределы каталога, потеря кода ошибки, доступ к секретам или отсутствие восстановления.

Итоговый выбор схемы для команды

Если текущая схема использует общий Mac с несколькими проектами, постоянной учётной записью и широкими сетевыми правами, она неудобна для AI Agent: трудно определить владельца файла, невозможно надёжно изолировать keychain, а восстановление после сбоя оставляет неоднозначное состояние.

Самостоятельная покупка Mac устраняет часть зависимости от общего узла, но добавляет стоимость оборудования, обслуживание, замену неисправностей, настройку доступа и необходимость постоянно держать машину доступной. Linux-сервер дешевле для обычных CI-задач, однако не заменяет macOS там, где нужны Xcode и Apple SDK. Виртуальная macOS-среда также не равна проверке на настоящем удалённом Mac: остаются вопросы совместимости, доступа к инструментам и стабильности.

Для пробного периода разумнее выбрать удалённый Mac с отдельной учётной записью, SSH-доступом и возможностью пересоздать окружение. Если команде важна география узла, варианты размещения можно сравнить, например, в описании аренды Mac mini в Сингапуре. Сначала запускаются сборка без подписи и тесты. Затем проверяются остановка, перезапуск и очистка. Только после этого рассматривается ограниченный процесс тестовой подписи.

SFTPMAC подходит как временная или изолированная среда, когда нужно быстро получить настоящий Mac для проверки Agent-сценария без покупки и постоянного обслуживания собственного узла. При этом долгие стабильные нагрузки, физические устройства, локальные периферийные интерфейсы и постоянные релизные операции всё равно требуют отдельного инженерного решения. Аренда не отменяет аудит прав — она лишь даёт удобный удалённый Mac, на котором такой аудит можно провести до подключения к рабочему контуру.