Greg Stein wrote on Mon, 13 Jul 2020 08:00 -0500:
> On Mon, Jul 13, 2020 at 6:34 AM Mark Phippard <markphip_at_gmail.com> wrote:
> > I'll lead with this stake-in-the-ground:
> > ** retain one week of nightly builds
> >
> >
> > +1 a week seems reasonable
> >
> Then we still have the "how many to retain?" question. I do like Mark's
> idea of maybe defining it as "7 builds" rather than "7 nights".
No reason we have to keep the most recent builds. We might as well
keep, say, the most recent N builds provided that no two of them are
from the same calendar month:
build()
all_builds = sorted(map(os.stat, glob.glob('*.gz')), key=operator.attrgetter('st_mtime'))
month_of = lambda x: x.st_mtime // (60 * 60 * 24 * 31)
if len(all_builds) > 7 and month_of(all_builds[-1]) == month_of(all_builds[-2]):
unlink(all_builds[-2])
all_builds[-2:-1] = []
if len(all_builds) > 7:
unlink(all_builds[0])
This should be more useful for bisecting.
Also, why seven? I'd rather keep as many builds as needed to go back
to before the branching point of the latest stable release. It's not
going to be that much disk space, is it? Assuming we discard .bz2 files
to save some disk space ("Let them use gzip!"):
20MB/nightly * 1 nightly/month * 24 months[minor line release period] = 0.5GB
(Don't know where your 50MB figure is from; on dist/ it's 25MB/release.)
Cheers,
Daniel
(Yes, I know there's datetime.somethingorother(st_mtime).strftime(),
but ENOTIME to look up what it's called…)
Received on 2020-07-13 15:49:18 CEST