Hello all, A bit of background on why Gavin is proposing this "time to culling" policy, is because we have been battling disk space issues on the Jenkins slaves for the past month or so. This suggested policy is needed to keep the nodes *useful*. If stuff gets culled, then it will just take builds a bit longer, but they will be POSSIBLE. Nodes that are disk-full won't build at all, so "slow vs never" seems a good tradeoff.
As noted other-thread, we've also moved the Jenkins Master to a faster machine, faster disks, and onto bare metal to avoid resource contention with other VMs. Jenkins is a ongoing work to keep this resource available to our projects. Unfortunately, it also suffers a bit of "tragedy of the commons", in that individual users don't realize their impact on all the other Foundation's projects. We speak to the outliers as we find them, but an overarching policy that people are aware of, that they can conform to (and/or we force conformance) will lead to better results for everybody using this shared resource. This list is also great for sharing best-practices (as has been done else-thread already!) will help all projects remain within the culling period. Regards, Greg Stein InfraAdmin, ASF On Mon, Jul 23, 2018 at 2:45 AM Gavin McDonald <ga...@16degrees.com.au> wrote: > HI All, > > I'd like to ask a basic question. > > Is there any reason at all to keep the 'workspace' dirs of builds on the > jenkins slaves ? > > If projects do not use the built in plugins to cleanup their workspaces, > INFRA has a script that will run periodically to do cleanups. > > My iniital thinking is that there is no reason at all to keep workspace > directories > and that a policy of 7 days would be plenty. > > And , in advance, I'd like to state that projects creating their own > storage area for jars > and other artifacts to quicken up their builds is not a valid reason. > > -- > --- > Gav... >
