2021-09-18 00:08 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0006361BuildbotBuildbotpublic2020-12-21 16:17
Assigned Toabma 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
Summary0006361: keep the last n builds
Descriptionatm builds are deleted by age, they should be deleted by age and the last n builds for the branch develop and maintenance should be kept.

TagsNo tags attached.
Attached Files

related to 0006394resolvedabma Spring engine get rid of 32 bit engine builds 



ThinkSome (reporter)

1. Are the windows x64 and linux x32 builds really necessary? Nobody seems to be using those, so keeping them around on expensive disks (servers) seems silly. Who uses the portables?

2. Ditto for the 120 MB win x32 debug packages. Store them home, on inexpensive storage and upload on request.

3. Scaleway offers 75GB per month of free object storage. That can store roughly 2500 version of lin64 and win32 builds (with some caching on frontend server).

4. How much (free) space does springrts.com server actually have?


ThinkSome (reporter)

Behold, the tutorial: https://www.scaleway.com/en/docs/setting-up-object-proxy-object-storage/


ThinkSome (reporter)

Ah, I see all builds have debug packages. Damn, 600 MB per version is a lot.

How much space is taken by all the maps @ springfiles? My server is also getting clogged by maps (2.5GB) and other stuff, so I was thinking of putting them all into object storage, anyway.


abma (administrator)

proxy the request to an object storage would double the traffic...

all maps on springfiles.com are ~50GB

IMHO your idea doesn't solve the problem: the real problem is, that we need a "stable" release. we can't store builds forever, so a cleanup is required: with or without object storage.


abma (administrator)

free disk space on springrts.com is currently ~100GB: thats mostly because very few new builds are created.

so a maybe a more advanced algorithm would take the available disk space into account: i.e. delete builds if few disk space is available and at least n builds are available.


ThinkSome (reporter)

It would double the traffic for builds that have to be taken from object storage, but since the front-end would do caching, that would be a very rare event (assuming large enough cache ~ 1 GB).

Builds absolutely *can* be stored forever, the questions are only: where they are stored, which parts of these are stored and if doing so is rational. 2-Duplicated home storage here is 1 eur per 100GB per year in hardware, and anywhere from 1 to 15 eur in electricity. object storage is $12 per 100GB per year. Server bulk storage HDD space is probably much more expensive.

Just moving the 120MB debug packages to home storage would go a long way, without having to delete anything on the server! 1474*(15MB linux64+15MB windows32) = 44 GB


abma (administrator)

the real cause of this problem is, that no stable release was made way to long.

as 105.0 is knocking on the door i don't see why the behaviour of the delete script should be changed.

"don't let the development / stable release cycle die" should be more important than trying to fix the symptoms.

-> https://springrts.com/wiki/Roadmap

-Issue History
Date Modified Username Field Change
2020-01-20 15:29 abma New Issue
2020-01-20 15:29 abma Assigned To => abma
2020-01-20 15:29 abma Status new => assigned
2020-03-26 22:40 abma Project Spring engine => Buildbot
2020-04-07 04:21 ThinkSome Note Added: 0020378
2020-04-07 13:33 ThinkSome Note Added: 0020379
2020-04-07 14:01 ThinkSome Note Added: 0020380
2020-04-07 22:22 abma Note Added: 0020381
2020-04-07 22:24 abma Note Added: 0020382
2020-04-07 23:18 ThinkSome Note Added: 0020383
2020-05-14 13:32 abma Relationship added related to 0006394
2020-12-21 16:17 abma Status assigned => closed
2020-12-21 16:17 abma Resolution open => no change required
2020-12-21 16:17 abma Note Added: 0020550
+Issue History