Кратко

  • GitHub по умолчанию хранит артефакты и журналы 90 дней. Изменение срока в репозитории влияет на новые файлы; существующие сохраняют дату истечения, установленную раньше.
  • Сверх включённого лимита хранение артефактов накапливается в гигабайт-часах. Удаление старого файла прекращает будущие часы, но уже учтённые остаются в расчёте за период.

Срок в настройках короткий, старый склад длинный

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

Обычный срок — 90 дней. Для публичного репозитория GitHub разрешает от одного до 90 дней, для частного — от одного до 400 дней с учётом ограничений организации. У каждого прежнего артефакта через API можно проверить expires_at. Его можно удалить досрочно, но восстановить потом нельзя. Прежде чем чистить старый архив, нужно отделить забытые сборки от файлов, необходимых для выпуска, проверки или расследования сбоя.

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

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

Источники