| 1 | # 0037 — Release assets count against a quota of their own |
| 2 | |
| 3 | **Status:** adopted |
| 4 | |
| 5 | ## Decision |
| 6 | |
| 7 | Release assets get a fourth storage kind, `asset`, with `ASSET_STORAGE_QUOTA_BYTES` as its environment default and |
| 8 | |
| 9 | Assets in forks still count against the `fork` limit, like everything else a fork holds (0035), the same split Git LFS objects follow (0036). `assetKindOf(repository)` picks the kind, as |
| 10 | |
| 11 | `StorageQuotaService.usageOf(account, kind)` sums only the rows of its kind: log entries and merged pull refs for `repository`, LFS objects for ` |
| 12 | |
| 13 | `GET /api/storage/:owner` reports the new limit as `asset`, and its top-level `usedBytes |
| 14 | |
| 15 | ## Why |
| 16 | |
| 17 | Release binaries grow with every release and are easy to delete and re-upload, while git data is permanent once pushed. Sharing one limit meant a few large releases could stop an account from pushing code, and an operator could not offer generous release storage without also raising the cap on git data. |
| 18 | |
| 19 | ## Consequences |
| 20 | |
| 21 | - An instance that sets `STORAGE_QUOTA_BYTES` and not `ASSET_STORAGE_QUOTA_BYTES` stops limiting release assets on upgrade, since an unset limit means unlimited. Operators who want them capped set the new variable. |
| 22 | - An account that was full only because of release assets can push again after the upgrade. |
| 23 | - The release form checks a fork's uploads against the fork limit and anyone else's against the asset limit, choosing by the repository's `parent`, as the API does. |