Can we move the builds temporarily and see if it affects workflows over a
few months and if not, then remove them?
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 ;)
> On Tue, May 15, 2018 at 12:53 PM, Randell Jesup <rjesup.n...@jesup.org>
> >>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
> > firstname.lastname@example.org
> > https://lists.mozilla.org/listinfo/dev-platform
> dev-platform mailing list
dev-platform mailing list