GitHub Actions: как отделить минуты выполнения от хранения артефактов

Сборки GitHub Actions запускаются редко, а расход всё равно растёт. Кроме выполнения workflows в расчёте может участвовать хранение. Поэтому смотреть только на число запусков недостаточно.

Откройте состав использования

Проверьте текущие правила для своего типа репозиториев и runners. Отдельно изучите артефакты и другие учитываемые объекты. Не считайте бесплатность одного сценария общим правилом для любой инфраструктуры.

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

• Сверьте длительность и частоту запусков.
• Проверьте размер сохраняемых артефактов.
• Уточните срок их хранения.
• Посмотрите детализацию расхода по репозиториям.

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

Оплата разных ресурсов

В NukaPay по GitHub уточните конкретный продукт и формат покупки. Подписка команды и metered usage не должны смешиваться в одном неопределённом запросе.

Итог — расход объясняется вычислением и хранением отдельно. Малое число сборок не гарантирует малый общий счёт.

Рабочий пример: от симптома к проверке

В GitHub Actions сборки укладываются в доступное время, но команда продолжает хранить тяжёлые artifacts. В счёте возникает отдельная статья использования. Это условный рабочий пример, а не история клиента и не обещание результата сервиса.

В этом случае нужны следующие исходные данные: runner, минуты, размер artifacts, срок хранения и действующая модель тарификации. Их лучше записать до изменения настроек. Иначе после нескольких попыток будет сложно понять, какое действие повлияло на результат и к какой версии относится наблюдение.

Контрольная проверка: сверка отчёта по времени выполнения с отдельным отчётом хранения. Сохраните исходное состояние, выполните проверку и сопоставьте результат с ним. Тест должен воспроизводить рабочую задачу, а не только подтверждать вход в сервис.

Ожидаемый итог для этого примера: расход каждой категории объясним, ненужные артефакты удаляются по согласованной политике. Это конкретный критерий приёмки. Факт входа в аккаунт, успешная оплата или исчезновение уведомления сами по себе ещё не подтверждают, что рабочая задача решена.

Ошибка, которая приводит к лишней покупке

Минуты Actions и хранение артефактов считают одним взаимозаменяемым лимитом. Такой результат требует диагностики до следующей покупки: новый ресурс сам по себе не подтверждает исправление причины.

Для artifacts задайте срок хранения по реальной цели: диагностика последней сборки и долгосрочная выдача релиза требуют разных подходов. Проверьте, не сохраняются ли одинаковые тяжёлые файлы в каждом job. Удаление нужного релиза ради экономии места — плохая замена политике хранения. Минуты и объём сверяйте по отдельным текущим правилам GitHub.

Как сформулировать заявку в NukaPay

Предмет заявки здесь: продукт GitHub и ресурсы Actions по раздельно измеренным времени и хранению. Перед оплатой найдите сервис в каталоге NukaPay и сопоставьте доступное предложение со своей задачей. Если название варианта не даёт однозначного ответа, уточните его состав, вместо того чтобы выбирать по одному совпадению бренда.

В заявке разделите три вопроса: что именно приобретается, к какому аккаунту или рабочей области относится покупка и какой период либо объём требуется. Для этого примера приложите несекретные сведения по пунктам: runner, минуты, размер artifacts, срок хранения и действующая модель тарификации. Полную стоимость и условия конкретного заказа проверяют до оплаты; чужой старый чек не подтверждает сегодняшнее предложение.

Пароль, код 2FA и доступ к почте NukaPay не запрашивает.

Что проверить после выполнения заказа

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

Источники

• Официальный источник 1