gitea

gitea copied to clipboard

Feature request:

Set up per-repo and / or per-instance rules for expiring release attachments, e.g. "keep at least for 90 days" and "keep at least 5 recent versions", maybe even with fine-tuning for stable series when using SemVer (keep recent asset from previous minor and all patches from current minor etc)

Gitea is a good demonstration here: Every release creates hundreds of Megabytes (Gitea 1.14.5 about 1.7 GiB) of release attachments. Hosting them forever sounds like a terrible idea in terms of energy consumption and e-waste for the hard drives, and also from a financial perspective. Especially because these release files are not primary data, but only a compilation of the tagged code. Once a release is no longer up to date, I don't see any reason for hosting the files for users. If someone needs an old version, they can simply compile the code again.

I therefore propose to do better with Gitea as a service: Set up expiry for release attachments, so the space can be freed up once the files are no longer necessary.

Thank you for considering :v:

Agreed, but I would add a few things:

1. I wouldn't make this a "choose one", I would rather use a combi of the two different approaches: "Delete old releases after X time if they are not one of the Y last (<release type>, if there was such a distinction) releases". Otherwise, you can have the problem that when a repo is feature-complete, it cannot be downloaded prebuilt anymore after that time has passed.
2. "keep at least 90 days" should rather be on the lower end of that scale: Even if you release every 2 weeks, which is definitely not too common, you would have only released 90/14 ~= 6 releases. If you release less often, which is most often the case, you would have even less releases until the attachment is deleted. As mentioned, that would only be useful when used in combination with the combi mentioned above.

Using this combi approach has even more benefits: It is most likely easier to implement, as to disable it you can then simply pass a value < 0 to both settings. Also, you don't have to switch between different deletion algorithms, making the code more readable, lightweight and most likely less buggy. 3. The default value should still be that no old releases are deleted, so you have to opt-in to autodelete release attachments (unless of course this would be a server-wide setting, but I'm much more in favor of a repo-wide setting).

Just to clarify once more - with

"keep at least for 90 days" and "keep at least 5 recent versions"

I mean that a release is only removed if there are more than 5 recent versions, and it is older than 90 days. If you have for example a release schedule that releases a new minor every two months, this would make sure that the previous once are available longer, even if patches and RCs account for more than 5 versions. Also, if development suddenly stops, the 5 versions rule makes sure that you keep 5 recent versions available for download.

It might also be worthy to allow a release to be marked for keeping, or maybe offer a checkbox during release that it should automatically expire - so you can opt-out for a certain release.

I read the feature request, and had a weird idea: would it be possible to use a custom, scheduled Action to achieve this? That would make it possible to have any kind of rules a particular project might wish for, however complicated they want it to be.

The downside, of course, is that it needs a bit more setup - and Actions enabled - to work, but is far more flexible than what Gitea could otherwise reasonably provide.

It does not help with instance-wide expiry rules, but... perhaps a per-user/per-org asset quota would help? That wouldn't make expiry automatic, but it would prevent the user/org to create more releases, and would force them to remove old assets - either manually, or automatically, as they see fit.

So a combination of quotas + Actions (perhaps with an official-ish expiry action) would go a long way, no?

I'd be happy to look into asset quotas, and can even write an example expiry action.

I also think moving this as an external cron job or actions will be better. For binary storage, S3/Minio is very suitable and cheaper and 1.7GB is not very big. Maybe we can close this issue.

I'd keep it open, because built-in quotas (when not using S3/Minio) would still be useful, and so would an example expiry action.

so would an example expiry action.

This is something I'm looking into at the moment. I self-host on a TrueNAS box so storage isn't a massive concern, but it'd still be nice to clean up old artifacts. Are you aware of an example lurking anywhere?