On Sun, 20 May 2018 at 19:40, Karl Tomlinson <mozn...@karlt.net> wrote:
> On Fri, 18 May 2018 13:13:04 -0400, Chris AtLee wrote:
> > IMO, it's not reasonable to keep CI builds around forever, so the
question
> > is then how long to keep them? 1 year doesn't quite cover a full ESR
cycle,
> > would 18 months be sufficient for most cases?
> >
> > Alternatively, we could investigate having different expiration policies
> > for different type of artifacts. My assumption is that the Firefox
binaries
> > for the opt builds are the most useful over the long term, and that
other
> > build configurations and artifacts are less useful. How accurate is that
> > assumption?
> Having a subset of builds around for longer would be more useful
> to me than having all builds available for a shorter period.
> The nightly builds often include large numbers of changesets,
> sometimes collected over several days, and so it becomes hard to
> identify which code change modified a particular behavior.
> I always use opt builds for regression testing, and so your
> assumption is consistent with my experience.
> I assume there are more pgo builds than nightly builds, but fewer
> than all opt builds. If so, then having a long expiration policy
> on pgo builds could be a helpful way to reduce storage costs but
> maintain the most valuable builds.
Here's a bit of a strawman proposal...What if we keep the
{mozilla-central,mozilla-inbound,autoland}-{linux,linux64,macosx64,win32,win64}{,-pgo}/
directories in tinderbox-builds for now, and delete all the others. Does
that cover the majority of the use cases for wanting to access these old
builds?
I'm guessing the historical builds for old esr branches aren't useful now.
Nor are the mozilla-aurora, mozilla-beta, mozilla-release, or b2g-inbound
builds.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
