Одна сумма минут в конце месяца не объясняет, почему macOS CI подорожал и что именно запускало задания.
Быстрое решение: сгруппируйте рабочие процессы по сценариям, посчитайте запуски и фактическое время заданий, добавьте повторы и хранение, а затем примените актуальные правила GitHub. Короткие изолированные задания сначала оценивайте для hosted Runner; постоянную отладочную среду считайте отдельно, прежде чем дополнять CI удалённым Mac.
Эта инструкция пригодится разработчикам научного ПО, которым нужно заложить бюджет на сборку и проверку под macOS; руководителям лабораторий, планирующим расходы закрытого репозитория; и специалистам, отвечающим за CI, которым важно отличать короткие задания от постоянно доступного рабочего места.
Последняя проверка: 27 сентября 2026 года. Правила и сведения о Runner сверены с официальной документацией GitHub Actions по биллингу, справочником по ставкам и учёту Runner и перечнем hosted Runner. Перед утверждением бюджета проверьте эти страницы ещё раз: цены, доступные льготы, метки и статус предварительных версий могут измениться.
Начните с разметки фактических сценариев CI
Для прогноза не умножайте условное число рабочих дней на произвольную длительность сборки. Возьмите представительный период журнала проекта и разделите задания по тому, зачем они запускаются. В каждом сценарии отдельно учитывайте частоту, фактическое время выполнения задания и повторные попытки. Минуты ожидания в очереди не подменяют длительность выполнения: фиксируйте эти показатели раздельно.
Основная модель расчёта выглядит так:
Оценка использования за период = сумма по сценариям (число запусков × учитываемая длительность заданий) + повторы + дополнительные задания матрицы.
Полученное использование ещё не является денежной суммой. Сначала определите, какие правила применяются к видимости репозитория и типу Runner, затем используйте ставки и доступные льготы, показанные для вашего аккаунта. Отдельно проверьте хранение артефактов и журналов: нельзя автоматически считать его включённым в стоимость выполнения или, наоборот, приписывать ему фиксированную плату без проверки условий.
В официальных материалах различаются стандартные hosted Runner и larger runner; правила применения зависят от типа машины и настроек учётной записи. Публичный и закрытый репозитории также нельзя объединять в одну строку бюджета: сначала проверьте, какие условия действуют именно для каждого из них. Официальная таблица тарификации Runner — источник для расчёта, а не чужой счёт или прежняя оценка из обсуждения.
Важно: не переносите бесплатный лимит, скидку или льготный режим из другого аккаунта на всю лабораторию. Подтвердите право на условия в настройках и официальной документации для своего репозитория.
Рассчитайте частые проверки после коммита
Быстрая сборка и smoke-тесты обычно запускаются чаще других задач. Именно поэтому небольшая ошибка в оценке частоты или повтора может заметно исказить месячный прогноз, даже если отдельное задание кажется коротким.
Соберите данные из журналов за период, который отражает обычную работу группы, включая активные этапы разработки и периоды с меньшим числом изменений. Для каждого запуска выпишите источник триггера, фактическую длительность задания, результат и факт повторной попытки. Если workflow создаёт несколько заданий параллельно, учитывайте их отдельно: календарное время всего workflow и суммарное время выполняющихся заданий — разные показатели для анализа расхода.
Затем разделите проверки на macOS-зависимые и переносимые. Форматирование, статический анализ или часть тестов могут не требовать Apple-среды, тогда как проверка сборки под macOS, платформенных API или поведения приложения в macOS — требуют. Не переносите задачу на другую платформу лишь ради экономии, если такой запуск перестанет проверять нужное условие. Цель — не уменьшить число macOS-заданий любой ценой, а не запускать их там, где результат не зависит от macOS.
Чтобы понять, какие триггеры создают лишнюю параллельную работу, проверьте правила синтаксиса workflow и группировки concurrency. Сопоставьте настройки с фактическими запусками: отмена устаревшей сборки полезна только тогда, когда новая сборка действительно заменяет старую и вы не теряете обязательную проверку.
Проверьте Xcode 27 и матрицу регрессии
Для проекта, которому нужны Xcode или инструменты платформы Apple, одной записи «macOS сборка» недостаточно. Перед бюджетированием уточните конкретную метку Runner, системную версию, архитектуру и состояние образа. Официальная запись о предварительном появлении Xcode 27 в Runner Images помогает проверить статус анонса; текущий состав образов смотрите в официальном репозитории Runner Images. Предварительный статус и доступность нужной конфигурации следует перепроверять непосредственно перед планированием тестов.
Разложите работу на отдельные категории: базовая сборка, проверки на нескольких системных версиях, подпись и упаковка, а также ручная приёмка. Если workflow запускает матрицу, число фактически созданных заданий зависит от её вариантов и условий пропуска. Не рассчитывайте стоимость одной сборки, а затем не умножайте её на предполагаемое число систем «на глаз»: посчитайте задания, которые действительно появились в журнале.
Для измерения длительности используйте уже завершённые запуски похожего кода, а для нового этапа — пробный запуск с той же матрицей и настройками. Оцените не только удачный результат: сбой подписи, нестабильный тест или ошибка, требующая повторной сборки, могут изменить фактический расход. Если задача требует ручного вмешательства между этапами, пометьте это отдельно — автоматическое задание и интерактивная сессия представляют разные потребности.
Учтите расписание, длительные задачи и повторы
Для ночного анализа, периодической регрессии и пакетной обработки сначала определите реальную частоту расписания, затем проверьте, сколько запусков действительно завершается. Фиксируйте отменённые, повторённые и прерванные задания отдельно. Если workflow прерывается из-за внешней зависимости, повтор может занимать столько же ресурсов, сколько обычный запуск; считать его бесплатным продолжением предыдущего нельзя без подтверждения правил учёта.
Ключевое различие — нужно ли задаче оставаться доступной после завершения отдельного workflow. Hosted Runner подходит для запуска изолированного задания, которое получает входные данные, выполняет работу и передаёт результат. Если исследователю нужно сохранять состояние среды, вручную исследовать сбой, повторять команды в той же сессии или работать с приложением до приёмки результата, это уже не просто CI-минуты. Для такой работы отдельно оцените постоянно доступную машину и способ подключения.
Для оценки частоты используйте фактические данные, а не число запланированных запусков. Метрики использования GitHub Actions помогут сверить картину с данными проекта и организации, но конкретный набор доступных показателей зависит от уровня и настроек. Сверяйте метрики с журналами workflow: агрегат показывает тенденцию, а записи конкретного задания объясняют, откуда взялся расход.
Добавьте к расчёту артефакты, кэш и сбои
Минуты выполнения — не весь операционный бюджет. Для каждого workflow проверьте, сохраняются ли журналы и артефакты, как долго они нужны группе и не остаются ли устаревшие сборки после завершения эксперимента. Правила хранения и доступные настройки описаны в официальной документации о сроках хранения артефактов и журналов.
Кэш зависимостей может ускорить повторную сборку, но его наличие не гарантирует ускорения каждого задания: промах кэша, смена ключа или изменение зависимостей могут вызвать повторную установку. Проверьте официальные правила кэширования зависимостей и изучите журналы своего проекта. Для бюджета запишите, какие данные сохраняются и используются ли повторно, вместо того чтобы закладывать неподтверждённую экономию.
Для реальной картины составьте отдельную ведомость: число неудачных запусков, их причина, количество повторов, размер и срок хранения результата. Не смешивайте повтор после временной сетевой ошибки с обязательным прогоном по новой версии кода: это разные основания для нагрузки и разные способы её сократить.
Сведите данные в рабочую таблицу
Заполняйте значения из журнала, а не из желаемого графика проекта. В поле со ставкой фиксируйте дату проверки официальной страницы и категорию Runner; сумму не переносите между аккаунтами, пока не подтверждены одинаковые условия.
| Сценарий | Что измерить по журналам | Что включить в оценку | Когда пересмотреть задачу |
|---|---|---|---|
| Проверка после коммита | Частота триггеров и длительность каждого задания | Повторные попытки и задания, созданные параллельно | Если проверка не использует специфичные возможности macOS |
| Сборка с Xcode | Метка Runner, образ, архитектура и реальные задания матрицы | Базовый запуск, дополнительные варианты и сбои | Если нужная версия инструментария или Runner изменила статус |
| Подпись и упаковка | Число запусков и этапов с подписью | Повтор после ошибки и сохранённые артефакты | Если требуется ручная проверка или сохранение состояния |
| Расписание и обработка данных | Фактическая частота, длительность и прерывания | Перезапуски и объём результатов | Если процессу нужна длительная интерактивная сессия |
| Поле учёта | Что записывать | Где подтвердить |
|---|---|---|
| Видимость репозитория | Публичный или закрытый; учитывайте репозитории раздельно | Настройки проекта и официальные правила биллинга |
| Тип и метка Runner | Стандартный или larger runner, выбранная метка и образ | Справочник hosted Runner и документация larger runner |
| Категория работы | Быстрая проверка, сборка, регрессия, подпись или расписание | Файл workflow и журнал запусков |
| Частота за период | Фактическое число созданных заданий | История запусков и метрики |
| Время задания | Длительность каждого задания, отдельно от ожидания в очереди | Журнал workflow |
| Повторы и матрица | Дополнительные задания, неудачи и повторные попытки | Записи workflow и условия матрицы |
| Хранение | Тип результата, объём по данным проекта и нужный срок | Настройки хранения и правила организации |
| Ставка и дата сверки | Значение для применимого типа Runner и аккаунта | Официальная страница биллинга на дату расчёта |
Выберите следующий шаг по сценарию, а не по одной сумме
Сравнение должно учитывать, что именно исследователь делает на машине. Короткая автоматическая проверка и постоянная рабочая среда не являются взаимозаменяемыми продуктами: одна выполняет задания по событию, другая помогает поддерживать доступное состояние для дальнейшей работы.
| Вариант | Лучше подходит для | Что оценить | Ограничение для бюджета |
|---|---|---|---|
| Стандартный hosted Runner | Коротких автоматических сборок и тестов | Частоту, длительность, матрицу, повторы и условия репозитория | Фактическая стоимость зависит от правил учёта и аккаунта |
| Larger runner | Заданий, которым требуется конфигурация из соответствующего перечня | Доступность нужного образа, тип Runner и его правила тарификации | Нельзя оценивать по ставке стандартного Runner |
| Постоянная удалённая среда Mac | Интерактивной отладки, ручной приёмки и работы с сохраняемым состоянием | Продолжительность потребности, доступ, требования команды и стоимость аренды | Это отдельная статья бюджета, а не способ пересчитать минуты CI |
Если вы рассматриваете Mac не только для CI, но и для постоянной командной работы, изучите руководство по аренде Mac M4 и страницу с условиями аренды Mac. Используйте их для отдельной оценки среды и условий, а не как замену расчёту по реальным запускам.
Заполните бюджет перед утверждением
Перед тем как согласовать расходы, пройдите по рабочему списку:
- Возьмите записи проекта за период, который отражает обычный цикл разработки.
- Разделите сборки, тесты, матрицы, подпись и задания по расписанию.
- Для каждого workflow посчитайте созданные задания, фактическую длительность и повторы.
- Укажите видимость репозитория и конкретный тип Runner.
- Отдельно проверьте сохранённые артефакты, журналы и кэш.
- Запишите дату сверки официальных ставок и условий.
- Если команде требуется постоянное взаимодействие с macOS, составьте для этого отдельную оценку.
Ответы для бюджетирования macOS CI
В закрытом проекте начните с условий именно того аккаунта, где размещён репозиторий; для публичного проекта тоже не делайте вывод о применимости правил по чужой настройке. Для обеих категорий используйте одинаковую методику измерений, но не обязательно одинаковые условия тарификации. Если группа работает в нескольких репозиториях, внесите их в бюджет отдельными строками и применяйте подходящие правила к каждому.
Для Xcode 27 универсальной длительности, после которой hosted Runner якобы становится невыгодным, нет. Проверьте доступность и статус нужной метки, затем измерьте проект на реальной матрице. Сопоставьте частоту запусков и повторы с потребностью в интерактивной отладке: первая часть относится к автоматизированному CI, вторая может потребовать иной формат среды.
Сбои могут увеличивать фактическое использование из-за повторного выполнения, а артефакты и журналы могут затрагивать отдельные настройки хранения. Проверьте workflow, историю запусков и правила retention; кэш анализируйте по журналам, а не по предположению, что он всегда сработает. Укажите эти составляющие отдельными строками и подтвердите, какие из них меняют сумму именно для вашего аккаунта.
Hosted Runner удобен для коротких воспроизводимых заданий, но не заменяет постоянно доступный Mac, если исследователю нужно взаимодействовать с приложением, сохранять состояние или многократно разбирать один и тот же сбой. Сначала измерьте долю таких задач и требования к доступу; затем сопоставьте их с расходом CI и условиями отдельной аренды. Если ручная работа редка, не оплачивайте постоянную среду без необходимости; если она регулярна, считайте её отдельной статьёй, а не скрывайте внутри средней длительности сборки.
Ведите расчёт по реальным workflow, регулярно обновляйте сведения о Runner и не утверждайте бюджет по устаревшей цене. Если измерения показывают, что лаборатории нужен не только запуск заданий, но и продолжительная отладка или ручная приёмка, сначала зафиксируйте требования к доступу и сохранению состояния. Затем проверьте, подходит ли аренда Mac от MACGPU для такого процесса; если работа полностью автоматизируется короткими заданиями, оставьте CI основным решением.