GitHub Actions или GitLab CI: минуты не равны минутам

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

На GitLab.com правила учёта GitLab дают бесплатному тарифу 400 вычислительных минут в месяц на пространство имён: длительность каждого задания в секундах делится на 60 и умножается на коэффициент исполнителя. Квота распространяется и на публичные проекты. Поэтому одинаковая по времени сборка может поместиться в лимит одной площадки и превысить лимит другой.

Что именно считается минутой

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

Тарифы исполнителей GitHub предусматривают округление каждого задания вверх до целой минуты: стандартный двухъядерный исполнитель на Линуксе стоит 0,006 доллара за минуту сверх квоты, увеличенный восьмиядерный — 0,022 доллара за минуту работы. Увеличенные исполнители доступны организациям с платными тарифами для команд или предприятий, оплачиваются отдельно и не расходуют включённые минуты. При условной длительности задания 4 минуты 10 секунд GitHub учтёт 5 минут, а GitLab на малом исполнителе с коэффициентом 1 — примерно 4,17 вычислительной минуты.

Округление особенно влияет на конвейеры из коротких заданий. Десять условных заданий по 5 секунд дадут GitHub 10 учитываемых минут. По формуле GitLab на малой машине они израсходуют вместе около 0,83 вычислительной минуты. Это сопоставление правил учёта при одинаковой заданной длительности; фактическое время выполнения зависит от окружения.

Открытый проект: когда размещённые сборки бесплатны

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

На GitLab.com те же условные 500 минут на малом исполнителе с коэффициентом 1 превысят квоту бесплатного тарифа на 100 вычислительных минут. Публичность репозитория сама по себе не снимает этот лимит. Для проектов, принятых в специальную программу поддержки открытого кода GitLab, действует пониженный коэффициент 0,5; его нельзя автоматически относить к любому открытому проекту.

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

Небольшой закрытый репозиторий: расчёт на месяц

Возьмём условную команду с 80 конвейерами за месяц. Каждый запускает два задания продолжительностью 4 минуты 10 секунд. На стандартном исполнителе GitHub каждое округлится до 5 минут: суммарный расход составит 800 минут и уложится во включённую квоту бесплатного тарифа. Если задания на малом исполнителе GitLab длятся столько же, получится около 667 вычислительных минут — приблизительно на 267 больше его бесплатной квоты.

Превышение квоты ещё не даёт готовой суммы счёта. GitLab позволяет приобрести дополнительные вычислительные минуты или перейти на тариф с большей квотой; цену выбранного варианта следует учитывать отдельно. У GitHub минуты и хранение результатов сборки тоже относятся к разным статьям расходов. Длительное хранение артефактов или увеличенный объём кэша в расчёт 800 минут не входят.

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

Тяжёлые параллельные сборки: мощность меняет расход

У размещённых исполнителей GitLab для Линукса малая машина имеет 2 виртуальных процессора и 8 ГБ памяти, средняя — 4 и 16 ГБ, большая — 8 и 32 ГБ; большая доступна на платных тарифах старших уровней. Их коэффициенты расхода составляют соответственно 1, 2 и 3. Сравнение двух машин по одному только числу процессоров остаётся приблизительным: память и среда исполнения тоже влияют на время задания.

Предположим, за месяц проходят 40 конвейеров, в каждом одновременно работают четыре восьмиядерных задания по 12 минут 20 секунд. Всего это 160 заданий. GitHub округлит каждое до 13 минут: получится 2080 оплачиваемых минут увеличенного исполнителя, или 45,76 доллара за его работу по указанной ставке. Цена необходимого платного тарифа в эту условную сумму не включена.

Большой исполнитель GitLab при той же условной длительности израсходует 5920 вычислительных минут: 160 заданий × 12 минут 20 секунд × коэффициент 3. Денежную стоимость этого объёма нельзя получить из коэффициента напрямую — она зависит от подписки и приобретённых минут. Параллельность ускорит появление результата конвейера, но не уменьшит сумму времени четырёх работающих исполнителей.

Собственные исполнители: другая структура затрат

Если команда запускает задания на собственных машинах, GitHub не взимает плату за минуты их работы. У GitLab.com проектные и групповые исполнители не расходуют квоту размещённых исполнителей. При этом команда оплачивает оборудование или облачные машины, обеспечивает обновления и хранение кэша, а также резерв мощности для одновременных сборок.

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

Что показывает опубликованный тест кэширования

В открытом тесте установки зависимостей с кэшем среднее время после первого запуска составило 18 секунд у конфигурации на GitHub и 82 секунды у конфигурации на GitLab.com. Исполнители и программные окружения различались; вариант с собственным исполнителем GitLab в том же тесте показал 37 секунд. Эти результаты относятся к конкретным связкам машины, окружения и кэша, а не к постоянной скорости платформ.

Разница во времени влияет сразу на ожидание разработчика и расход оплачиваемых минут, поэтому скорость имеет значение для выбора. Но секунды из чужого теста нельзя напрямую подставить в бюджет команды с иными зависимостями и исполнителями. Для оценки расходов нужны длительности её типичных заданий: к каждому запуску применяется округление GitHub либо коэффициент GitLab, после чего месячная сумма сопоставляется с квотой и условиями подходящего тарифа.

Читайте также:

• Claude настроил лазер QuEra за секунды — эксперту требовались минуты
• Клип ВКонтакте может длиться три минуты: как снять и выложить ролик
• Цена минуты больше не решает: как выбрать каршеринг для конкретной поездки