Prune old Crucible release assets in the release workflow #52

New Issue

2026-07-25T12:09:28Z

archvillainette commented

2026-07-25 12:09:28 +00:00

Found during a disk audit of ovh-main (sow-platform #81). Crucible release assets were the second-largest reclaimable item on the production host disk.

What was found

Every sow-tools release published a full cross-platform binary set — 9 assets, about 57 MB per tag — and nothing ever deleted one. 31 releases had accumulated 1.8 GB inside Gitea, on the same 75 GB disk that runs Gitea, NodeBB, Traefik and (soon) the NWN testing server.

Nothing depends on an old asset: CI fetches the Crucible binary through a Nix flake pointing at the repo, not at a pinned release asset. Only the newest build is ever used.

What was already done

Assets were deleted from the 29 tags between v0.2.1 and v0.3.21 (261 files, roughly 1.65 GB), keeping v0.3.22 complete. v0.2.0 still holds its 9 assets — tea cannot address it because its release lookup pages at 30 — so those need clearing in the web UI.

Tags, source archives and release notes were untouched everywhere. Every deleted binary is reproducible from its tag.

What this issue asks for

Make the pruning automatic so it does not silently rebuild.

After a release publishes, delete the assets from all but the newest 2 tags. Two rather than one so a release in flight never leaves the previous download broken.

Notes for whoever picks this up:

Gitea has no built-in release-asset retention. This has to be a step in the release workflow.
The Gitea API path is DELETE /repos/{owner}/{repo}/releases/{id}/assets/{asset_id}; list releases, skip the newest 2, delete each remaining release's assets.
Deleting assets must never delete the release or its tag.
Failing to prune should not fail the release. Log a warning; a stale asset is cheaper than a blocked publish.
If a checksum file such as SHA256SUMS is meant to stay readable for older versions, say so and exclude it — otherwise it goes with the rest.

Related: sow-platform #97 tracks the same missing-retention problem across the container registry, the local asset cache, and the Bunny release tree.

Found during a disk audit of ovh-main (sow-platform #81). Crucible release assets were the second-largest reclaimable item on the production host disk. ## What was found Every `sow-tools` release published a full cross-platform binary set — 9 assets, about 57 MB per tag — and nothing ever deleted one. 31 releases had accumulated **1.8 GB** inside Gitea, on the same 75 GB disk that runs Gitea, NodeBB, Traefik and (soon) the NWN testing server. Nothing depends on an old asset: CI fetches the Crucible binary through a Nix flake pointing at the repo, not at a pinned release asset. Only the newest build is ever used. ## What was already done Assets were deleted from the 29 tags between `v0.2.1` and `v0.3.21` (261 files, roughly 1.65 GB), keeping `v0.3.22` complete. `v0.2.0` still holds its 9 assets — `tea` cannot address it because its release lookup pages at 30 — so those need clearing in the web UI. Tags, source archives and release notes were untouched everywhere. Every deleted binary is reproducible from its tag. ## What this issue asks for Make the pruning automatic so it does not silently rebuild. After a release publishes, delete the assets from all but the newest 2 tags. Two rather than one so a release in flight never leaves the previous download broken. Notes for whoever picks this up: - Gitea has no built-in release-asset retention. This has to be a step in the release workflow. - The Gitea API path is `DELETE /repos/{owner}/{repo}/releases/{id}/assets/{asset_id}`; list releases, skip the newest 2, delete each remaining release's assets. - Deleting assets must never delete the release or its tag. - Failing to prune should not fail the release. Log a warning; a stale asset is cheaper than a blocked publish. - If a checksum file such as `SHA256SUMS` is meant to stay readable for older versions, say so and exclude it — otherwise it goes with the rest. Related: sow-platform #97 tracks the same missing-retention problem across the container registry, the local asset cache, and the Bunny release tree.

archvillainette referenced a pull request that will close this issue

2026-07-29 07:51:21 +00:00

feat(ci): prune release assets outside the newest two tags (#52) #70

archvillainette referenced this issue from a commit

2026-07-29 07:51:22 +00:00

feat(ci): prune release assets outside the newest two tags (#52)

archvillainette closed this issue

2026-07-29 08:51:25 +00:00

archvillainette referenced this issue from a commit

2026-07-29 08:51:26 +00:00

feat(ci): prune release assets outside the newest two tags (#52) (#70)

Sign in to join this conversation.