The discussion about what to do about these particular buildbot builds has naturally shifted into a discussion about what kind of retention policy is appropriate for CI builds.
I believe that right now we keep all CI build artifacts for 1 year. Nightly and release builds are kept forever. There's certainly an advantage to keeping the CI builds, as they assist in bisecting regressions. However, they become less useful over time. 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? Archiving these artifacts into Glacier would cut the cost of storing them significantly, but also make them much harder to access. It can take 3-5 hours to retrieve objects from Glacier, and we would need to implement some API or process to request access to archived objects. On Thu, 17 May 2018 at 10:33, Mike Kaply <mka...@mozilla.com> wrote: > Can we move the builds temporarily and see if it affects workflows over a > few months and if not, then remove them? > > Mike > > On Thu, May 17, 2018 at 9:22 AM, Tom Ritter <t...@mozilla.com> wrote: > > > I agree with ekr in general, but I would also be curious to discover > > what failures we would experience in practice and how we could > > overcome them. > > > > I think many of the issues experienced with local builds are > > preventable by doing a TC-like build; just build in a docker container > > (for Linux/Mac) and auto-build any toolchains needed. (Which would be > > part of bisect in the cloud automatically.) I've been doing this > > locally lately and it is not a friendly process right now though. > > > > Of course on Windows it's an entirely different story. But one more > > reason to pursue clang-cl builds on Linux ;) > > > > -tom > > > > > > On Tue, May 15, 2018 at 12:53 PM, Randell Jesup <rjesup.n...@jesup.org> > > wrote: > > >>On 5/11/18 7:06 PM, Gregory Szorc wrote: > > >>> Artifact retention and expiration boils down to a > > >>> trade-off between the cost of storage and the convenience of > accessing > > >>> something immediately (as opposed to waiting several dozen minutes to > > >>> populate the cache). > > >> > > >>Just to be clear, when doing a bisect, one _can_ just deal with local > > >>builds. But the point is that then it takes tens of minutes per build > as > > >>you point out. So a bisect task that might otherwise take 10-15 > minutes > > >>total (1 minute per downloaded build) ends up taking hours... > > > > > > Also (as others have pointed out) going too far back (often not that > > > far) may run you into tool differences that break re-building old revs. > > > Hopefully you don't get variable behavior, just a failure-to-build at > > > some point. I'm not sure how much Rust has made this worse. > > > > > > -- > > > Randell Jesup, Mozilla Corp > > > remove "news" for personal email > > > _______________________________________________ > > > dev-platform mailing list > > > dev-platform@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-platform > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
