GitHub Actions macOS 26: какую архитектуру выбрать для корпоративного CI? 2026

Сборки macOS 26 проходят на Runner, но команда не уверена, можно ли уже отключить Intel.

Быстрый вывод: для основной CI-линии сначала проверяйте Apple Silicon; Intel оставляйте только для конкретных зависимостей, старой среды или выпуска, для которых есть подтверждённые требования. Не переключайте всё по одной метке Runner или одному зелёному запуску.

Кому полезен этот разбор

IT- и закупочным руководителям — чтобы выбрать архитектуру и планировать Mac-ресурсы.
Платформенным инженерам — чтобы проверить, где фактически выполняются GitHub Actions.
Прикладным и QA-руководителям — чтобы доказать совместимость сборки, тестов, подписи и выпуска.

Последняя проверка — 7 ноября 2026. Актуальность меток и образов сверялась с официальным объявлением о доступности macOS 26, документацией GitHub по Runner и репозиторием Runner Images. Поскольку метки и образы могут меняться, перед изменением CI проверяйте эти источники повторно.

IT и закупки: выбирайте не название Runner, а подтверждённый сценарий

GitHub объявил macOS 26 доступной для GitHub-hosted runners 26 февраля 2026 года. В официальной документации для macOS 26 указываются варианты на Apple Silicon и Intel; конкретные метки и их доступность следует сверять по текущим материалам GitHub. Это отвечает на вопрос о том, какие среды можно запросить, но не о том, будет ли совместим ваш проект.

В корпоративном решении полезно разделить три задачи:

• Платформа для основной очереди. Выберите архитектуру, на которой проходят штатные сборка, тестирование и выпуск.
• Совместимость. Выясните, есть ли зависимости, инструменты или сценарии релиза, которые требуют другого процессорного окружения.
• Ответственность за эксплуатацию. Определите, кто обновляет workflow, разбирает расхождения и утверждает удаление резервного пути.

Поэтому сравнивайте архитектуры по требованиям проекта, а не по предположению, что более новая система автоматически подходит всем. Для закупочного решения также имеет значение, кто отвечает за доступность нужной среды и где описаны её реальные характеристики. Если оценивается удалённый Mac, сверяйте условия и доступную информацию отдельно — например, в описании цен на аренду Mac mini. Эта информация помогает оценить ресурсную модель, но сама по себе не подтверждает совместимость вашего workflow.

Архитекторы приложений: отделяйте запуск от совместимости

Слово «собралось» описывает только один этап. Оно не доказывает, что зависимости корректно разрешились, тесты выполнились в нужном окружении, архив создан ожидаемым способом, а подпись и последующая доставка проходят без изменений.

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

Универсальный бинарный файл — возможный способ поддерживать несколько архитектур, но не универсальная гарантия совместимости всего приложения. Документация Apple объясняет построение универсального macOS-бинарного файла для Apple Silicon и Intel; это относится к соответствующим бинарным файлам, а не автоматически к любому стороннему плагину, скрипту или инструменту в цепочке. Проверяйте фактический состав зависимостей и используйте описание Apple для universal macOS binary как технический ориентир, а не как заключение о вашем проекте.

Платформенные инженеры: подтвердите архитектуру в самом запуске

runs-on определяет, какой Runner запрашивает workflow. Но одна только строка в YAML не служит доказательством архитектуры, на которой реально выполнилась задача. Сопоставьте конфигурацию с запуском и его журналом. GitHub описывает выбор GitHub-hosted runners и их метки, а также синтаксис назначения среды в workflow.

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

jobs:
  build:
    strategy:
      fail-fast: false
      matrix:
        include:
          - runner: macos-26
            target: apple-silicon
          - runner: macos-26-intel
            target: intel
    runs-on: ${{ matrix.runner }}
    steps:
      - uses: actions/checkout@v4
      - name: Record runner architecture
        run: |
          echo "target=${{ matrix.target }}"
          echo "uname=$(uname -m)"
          echo "runner_arch=$RUNNER_ARCH"
      - name: Build
        run: ./ci/build.sh

Проверяйте фактический вывод, а не ожидаемое значение из конфигурации. Например, uname -m обычно показывает arm64 на Apple Silicon и x86_64 на Intel, а RUNNER_ARCH в журнале помогает сопоставить окружение с данными Runner. Сохраните вывод вместе с идентификатором запуска и коммитом; детали доступных сведений для диагностики приведены в руководстве GitHub по просмотру журналов workflow.

target=apple-silicon
uname=arm64
runner_arch=ARM64

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

QA и релиз: сравнивайте одинаковый коммит по всей цепочке

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

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

Безопасность и эксплуатация: разделяйте метки и границы доступа

Разные Runner-метки в workflow не означают, что команда получила изолированные друг от друга машины или идентичные политики безопасности. Доступность секретов, область разрешений, способ запуска задачи и аудит зависят от фактической конфигурации репозитория и организации. Сопоставьте обе ветки с рекомендациями GitHub по безопасному использованию Actions, включая разрешения workflow и обращение с секретами.

До включения двухархитектурной матрицы назначьте владельца для каждого из этих пунктов:

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

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

Важно: тег в runs-on выбирает Runner, но не является политикой изоляции. Границы доступа определяются настройками workflow, репозитория, организации и среды выполнения — их нужно проверять отдельно для каждого пути.

Технические руководители: задайте срок пересмотра Intel-пути

Постоянно держать оба пути «на всякий случай» — тоже архитектурное решение. Оно требует поддержки двух конфигураций, внимания к обновлениям и отдельного разбора расхождений. Но отключать Intel до закрытия реального требования столь же рискованно. Управляемый вариант — зафиксировать причину каждой оставленной Intel-задачи и условие, при котором её можно пересмотреть.

Удобно оформить решение в записи для каждой критичной группы workflow:

1. Назначить целевую архитектуру. Начните проверку основной линии на Apple Silicon.
2. Зафиксировать исключение. Для Intel укажите компонент, сценарий или требование выпуска, а не общее «так исторически сложилось».
3. Определить доказательство. Запишите необходимые тесты и артефакты, которые подтвердят переход.
4. Назначить владельца и пересмотр. Не оставляйте исключение без ответственного и условия повторной оценки.
5. Утвердить изменение. Владелец платформы подтверждает workflow, QA — тесты, релизный ответственный — выпуск.
6. Удалить только закрытый путь. Если подтверждённого потребителя больше нет и критический процесс прошёл целевую проверку, оформите отключение и сохраните результаты как основание решения.

Упрощённое правило выглядит так: если ключевые этапы прошли проверку на Apple Silicon, назначайте эту архитектуру основной; если подтверждённое требование остаётся только у части задач, оставьте Intel для этих задач; если команда не может объяснить, кто и зачем использует Intel, внесите исключение в план пересмотра, а не сохраняйте его бессрочно.

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

Частые вопросы об архитектуре macOS 26

В чём практическая разница между Apple Silicon и Intel Runner?

Официальные метки указывают на разные архитектуры: macOS 26 на Apple Silicon и macOS 26 на Intel. Это не доказательство совместимости конкретного проекта. Сравнивайте не только обозначение Runner, но и фактическую архитектуру в журнале, нативные зависимости, результаты тестов и полный путь до подписанного артефакта. Значения меток и доступность образов проверяйте перед изменением рабочего процесса.

Когда корпоративному iOS CI всё ещё нужна среда Intel?

Оставляйте Intel-задачу, если есть проверяемая причина: зависимость без подтверждённой поддержки Apple Silicon, обязательная проверка совместимости со старой средой или требование выпуска, которое не прошло испытание на целевой архитектуре. Запишите конкретный компонент, владельца и критерий повторной проверки. Одного исторического использования Intel или успешного запуска компиляции недостаточно, чтобы обосновать постоянное содержание отдельного пути.

Как подтвердить совместимость сборки и подписи после смены архитектуры?

Запустите один и тот же зафиксированный коммит на обеих архитектурах. Сохраните сведения об ОС и архитектуре из журнала, затем проверьте разрешение зависимостей, компиляцию, критические автоматизированные тесты, архивирование, подпись и доступность артефакта для следующего этапа. Успешный одиночный запуск — только начальное наблюдение; для допуска к выпуску нужны повторяемый результат и утверждение ответственных за CI и релиз.

Когда можно удалить Intel из двухархитектурного CI?

Удаляйте Intel-путь, когда у него больше нет подтверждённого потребителя, зависимости и релизные требования проверены на выбранной архитектуре, а ответственные команды согласовали результаты. Сначала назначьте дату пересмотра и временно сохраняйте наблюдаемость по очередям и запускам. Если остаётся обязательный сценарий без эквивалентного подтверждения, оставьте только соответствующую задачу на Intel и определите условие её повторной оценки.

Подбирайте Mac-ресурс после проверки рабочего процесса

Переход от штатной CI-платформы к собственному Mac или удалённой машине меняет не только архитектуру. У самостоятельной инфраструктуры есть расходы на приобретение, размещение, обслуживание и замену; у удалённой — нужно проверить доступность нужного окружения, условия доступа, ответственность за обслуживание и соответствие требованиям команды. Ни одна модель не отменяет проверки зависимостей и релизного процесса.

Для долгосрочной стабильной нагрузки и требований к физическим интерфейсам собственный Mac может быть уместнее. Если же команда сначала проводит ограниченную проверку или временно добавляет Mac-ёмкость, можно сопоставить задачу с вариантами аренды Mac у SFTPMAC и проверить опубликованные условия и доступные сведения. Не следует считать аренду автоматически более дешёвой или производительной: решение зависит от загрузки, безопасности, требуемой архитектуры и условий обслуживания. Сначала зафиксируйте результаты двойной проверки и оставшиеся Intel-исключения; затем выбирайте ресурс под подтверждённую потребность, а не под непроверенное предположение.