From 2c03921d23c83818053ccee2459f1c58ce7c6823 Mon Sep 17 00:00:00 2001 From: Ivan Fontosh Date: Thu, 14 May 2026 00:18:30 +0800 Subject: [PATCH] docs: updates repo size, GC, and 1.5 GiB expectations Co-authored-by: Cursor --- docs/GITEA_AUTO_UPDATE.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/docs/GITEA_AUTO_UPDATE.md b/docs/GITEA_AUTO_UPDATE.md index 38ab95c..239c5f0 100644 --- a/docs/GITEA_AUTO_UPDATE.md +++ b/docs/GITEA_AUTO_UPDATE.md @@ -394,6 +394,39 @@ git push origin v1.0.1 --- +## Размер репозитория `DndGamePlayerUpdates` (почему ~4 GiB и как держать меньше) + +### Почему место не возвращается само + +При **`DND_UPDATES_SQUASH_HISTORY=1`** и **`git push --force-with-lease`** на ветке **`updates`** в истории остаётся по сути **один актуальный коммит**, но на **диске сервера** Git до **сборки мусора** продолжает хранить **недостижимые** объекты: старые коммиты, прерванные push, временные ветки **`updates-upload-*`**, старые pack-файлы. Пока не выполнен **`git gc --prune`**, размер каталога **`.git`** на Gitea может быть **сильно больше**, чем «один релиз файлов» в веб-интерфейсе. + +### Сразу освободить место (один раз на сервере) + +На машине Gitea найдите **bare**-репозиторий (типичный путь: `…/gitea-repositories/<владелец>/dndgameplayerupdates.git`), от имени пользователя с правами на каталог: + +```bash +cd /path/to/DndGamePlayerUpdates.git +git gc --prune=now +``` + +При очень большом накоплении мусора иногда используют **`--aggressive`** (дольше и тяжелее для CPU); чаще достаточно команды **без** него. После GC размер на диске должен приблизиться к сумме **текущих** файлов в последнем коммите. + +В веб-интерфейсе Gitea смотрите раздел **администрирования** / **обслуживание** / **garbage collection** (названия зависят от версии): там может быть глобальный GC по всем репозиториям. + +### Чтобы после каждого релиза снова не раздувалось + +В **`app.ini`** Gitea включите **периодический GC репозиториев** (секция и ключи зависят от версии; ориентир — задача **`git_gc_repos`** в документации [config cheat sheet](https://docs.gitea.com/administration/config-cheat-sheet)), например раз в **24 ч** или чаще, если релизы частые. + +Уже включено в вашем пайплайне по смыслу: **squash** + **prune** старых имён установщиков — это уменьшает **набор файлов** в новом коммите; **физическое** освобождение на диске — задача **GC на сервере**. + +### Можно ли «всегда не больше 1,5 GiB» + +**Жёстко задать потолок Git не умеет.** Реальный минимум на диске ≈ размер **текущих** артефактов в ветке (два AppImage + NSIS + zip + blockmap + mac и т.д.) плюс служебные pack’и. Если один релиз по сумме бинарников уже **> 1,5 GiB**, репозиторий физически не уместится в лимит без **урезания артефактов** (например не выкладывать **`win.zip`**, если он не нужен updater’у) или без **выноса больших файлов из Git**. + +Надёжный способ держать репо **маленьким постоянно**: в **`DndGamePlayerUpdates`** хранить только **`latest*.yml`** (и при необходимости подписи), а **`.exe` / `.AppImage` / `.zip`** выкладывать в **Gitea Releases**, **объектное хранилище** или **статический хост**, а в yml подставлять **прямые URL** туда. Тогда потребуется доработка **CI** и, при смене хоста, **`build.publish.url`** / секреты — это отдельная схема доставки, не только `git gc`. + +--- + ## Если push отклонён: `(fetch first)` / `rejected` Пока job собирает артефакты, в **`updates`** мог успеть попасть **другой** коммит (второй релиз, ручная выкладка). Скрипт `sync-update-feed.mjs` перед push (в режиме **без** squash) делает **`git fetch` + `git merge origin/updates`** (и после клона — то же в начале), плюс shallow **глубина** (`DND_UPDATES_CLONE_DEPTH`: по умолчанию **40**, при **`DND_UPDATES_SQUASH_HISTORY=1`** в скрипте по умолчанию **8**). В режиме **squash** перед финальным push merge **не** выполняется — уже смерженное дерево отправляется через временную ветку и затем публикуется force-with-lease. Не запускайте **два релиза одного и того же репо одновременно** по двум тегам — возможны конфликты merge.