We were facing pretty much facing the same issue everyone has come across 
by now I think: constant alerting on full disk on the vm where the 
go-server lives. Though there is a lot to say for project management of 
stuff that is being run inside the pipelines and what it saves onto the 
server in a typical build (e.g. massive test reports from certain suites), 
all in all it will fill up slowly as no build is ever discarded. With many 
projects a real headache!

Before looking on groups or the www extensively I just went to work and 
re-invent the wheel (of course) and I wrote a small shell script to get rid 
of the old builds that usually are obsolete in a fast progressing 
environment. I've put it on github: 
https://github.com/LeoK80/go-server-cleanup . Feel free to fork it and make 
fit for your own purposes or just use it out-of-the-box. Readme will tell 
you all you need to know about its use.

Defaults:
- go-server artifacts directory '/var/lib/go-server/artifacts/pipelines'
- keep anything younger than 180 days
- never delete from a pipeline when there is 15 or less builds present
There is parameter input provided for retention & minimum of builds to keep


On Wednesday, April 29, 2015 at 10:20:20 PM UTC+1, Jason D wrote:
>
> Due to problems the default artifact cleanup algorithm of GO can 
> potentially cause, we have decided to turn it off and write our own.
>
> Our simple script currently just cycles through the artifacts and deletes 
> all but the latest xx (configurable) for every pipeline.  Very simple place 
> to start and it works well.
>
> We'd now like to add a bit more sophistication which brings me to the 
> questions I have for you all.
>
> Is there a programatic way (via the GO api, I assume) to tell if a 
> particular artifact set has been successful or not, given only the info 
> available from the file system for artifacts?  In the next iteration we'd 
> like to tighten it up a bit and save, for instance, the last xx artifact 
> sets that were the result of a pipeline that completed successfully, or 
> similar.
>
> If others have ideas on how you have managed this issue, I'd be grateful 
> for your feedback.
>
> Thanks.
> jason
>

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to