Сколько стоит CI в GitHub Actions: считаем минуты и деньги

Одна сборка, которая занимает восемь минут, при 30 запусках в день и 22 рабочих днях за месяц даст 5280 минут работы runner’а. Это пример для одного job на запуск, а не тарифный расчёт: итоговая сумма зависит от плана GitHub, типа runner’а и действующих правил биллинга. Ниже разбираем GitHub Actions с размещёнными GitHub runner’ами — у сервиса нет фиксированной пользовательской версии, а цены и включённые лимиты нужно сверять перед расчётом на официальной странице.

За что именно выставляют счёт

В GitHub Actions нельзя оценить CI только по длительности от открытия pull request до зелёной галочки. В расчёте важны job’ы, которые выполняются на runner’ах, тип операционной системы и число запусков. Если workflow запускает проверку, сборку и тесты как три отдельных job’а, их время складывается, даже когда часть работы идёт параллельно.

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

На сумму также влияют включённые в план минуты и условия для конкретного репозитория. Условия для публичных и приватных репозиториев могут различаться. Не переносите цену из старого отчёта или чужой статьи: перед бюджетированием откройте раздел GitHub Billing и проверьте тип runner’а, ставку, включённый объём и порядок округления.

Главная метрика CI — не минуты одной сборки, а оплачиваемые минуты на одну проверенную ветку или pull request.

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

Возьмём условный проект: один job занимает восемь минут, в день запускается 30 проверок, в месяце — 22 рабочих дня. Расчёт даёт 8 × 30 × 22 = 5280 минут runner’а за месяц. Это базовая оценка до учёта повторных запусков, дополнительных job’ов, различий между типами runner’ов и правил округления.

Теперь изменим не длительность, а структуру workflow. Если на каждый запуск добавляются ещё два job’а по четыре минуты, получится 8 + 4 + 4 = 16 минут runner’а на проверку. При тех же 30 запусках в день и 22 рабочих днях — 10 560 минут за месяц. Время ожидания может вырасти не вдвое, если job’ы идут параллельно, но суммарное использование runner’ов удвоится.

Это не цена в деньгах: подставлять одну универсальную стоимость минуты нельзя. Переведите объём в деньги по актуальной ставке для выбранной конфигурации в GitHub Billing. Если у вас несколько типов runner’ов, считайте каждый отдельно: 5280 минут Linux и 5280 минут macOS нельзя автоматически складывать как эквивалентные по цене.

Что снять перед расчётом

• Сколько workflow-запусков приходится на день или месяц, включая повторные запуски после ошибок.
• Сколько job’ов выполняется на один запуск и сколько длится каждый.
• На каких runner’ах они работают: операционная система и тип размещения.
• Сколько минут уже включено в ваш план и как GitHub считает превышение.
• Есть ли расходы, не связанные с минутами: например, хранение артефактов или использование дополнительных сервисов.

Ориентируйтесь на фактические данные в разделе использования GitHub Actions и сопоставляйте их с историей запусков. Средняя длительность одной сборки скрывает главное: частые повторные запуски и отдельные тяжёлые job’ы способны составить большую часть месячного расхода.

Термин. Runner — виртуальная или физическая машина, на которой GitHub Actions выполняет job. Оплачиваемые минуты — единица учёта использования runner’а; правила начисления и стоимость зависят от условий GitHub и конфигурации.

Где искать лишние расходы

Повторные запуски и слишком частые проверки

Один workflow может запускаться на push, открытие pull request, обновление ветки и расписание. Каждое событие потенциально создаёт новый запуск. Посмотрите, сколько запусков реально заканчиваются полезной проверкой, а сколько повторяют ту же работу, пока предыдущая сборка уже неактуальна.

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

Кэш, артефакты и раздутые job’ы

Кэш зависимостей помогает не скачивать и не собирать всё заново, но он не бесплатен по времени и не гарантирует ускорение. На небольшом проекте создание и восстановление кэша иногда съедают выигрыш. Сравните длительность одинаковых job’ов с кэшем и без него на достаточном числе запусков; отдельно проверьте, не меняются ли ключи кэша при каждом коммите.

Артефакты тоже требуют внимания: сборка может сохранять большие файлы, которые затем скачивают другие job’ы или хранят длительное время. Проверьте объём, срок хранения и необходимость каждого набора. Точные правила и цены хранения сверяйте в биллинге, а не прибавляйте их к стоимости минут на глаз.

Три способа управлять затратами

Что ломается в оценке

Самая частая ошибка — умножить время одной удачной сборки на число рабочих дней. В реальном проекте есть повторные запуски, тесты на разных версиях окружения, ночные workflow и неудачные попытки. Измеряйте период, который включает обычные пики разработки, иначе бюджет получится искусственно низким.

Вторая ловушка — сравнить hosted и self-hosted только по счёту за минуты. У собственной машины есть цена даже тогда, когда она простаивает: оборудование или аренда, обновления, мониторинг и время инженеров. Сравнивайте одинаковую нагрузку и включайте в расчёт обслуживание, а не только стоимость виртуальной машины.

Границы подхода тоже важны. Оптимизация запусков не поможет, если большую часть времени занимает одна необходимая интеграционная проверка. А сокращение тестов ради меньшего счёта может увеличить цену ошибок в продакшене. Сначала разделите расход по workflow и job’ам, затем выбирайте, что менять.

Что делать дальше

Выгрузите данные использования GitHub Actions за типичный месяц и сгруппируйте их по workflow, job’ам и runner’ам. Для каждого крупного потребителя посчитайте минуты на один успешный pull request, а не только среднюю длительность запуска. Затем проверьте актуальный тариф и включённый объём в GitHub Billing, выберите одну оптимизацию и сравните показатели до и после на сопоставимом периоде.