On Tue, 29 May 2018 at 14:21, L. David Baron wrote:
>
> On Monday 2018-05-28 15:52 -0400, Chris AtLee wrote:
> > 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
On Monday 2018-05-28 15:52 -0400, Chris AtLee wrote:
> 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 majo
On Sun, 20 May 2018 at 19:40, Karl Tomlinson 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 suffi
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
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
On Sun, May 13, 2018 at 8:00 AM, Jean-Yves Avenard
wrote:
> Hi
> On 12/05/2018 04:47, Boris Zbarsky wrote:
>
>> 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 th
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 wrote:
> I agree with ekr in general, but I would also be curious to discover
> what failures we would experience in practice and h
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
>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
Hi
On 12/05/2018 04:47, Boris Zbarsky wrote:
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
On Fri, May 11, 2018 at 4:06 PM, Gregory Szorc wrote:
> On Wed, May 9, 2018 at 11:01 AM, Ted Mielczarek
> wrote:
>
> > On Wed, May 9, 2018, at 1:11 PM, L. David Baron wrote:
> > > > mozregression won't be able to bisect into inbound branches then,
> but I
> > > > believe we've always been expiri
On 5/11/18 11:28 PM, Gregory Szorc wrote:
You could trigger dozens of builds on Taskcluster and they would all come back
in the time it
takes a single build to run.
This is doable, and basically corresponds to doing N-ary search for N>2.
With some tooling support so you don't have to pick th
On Fri, May 11, 2018 at 7:47 PM, Boris Zbarsky 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 t
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
On Wed, May 9, 2018 at 11:01 AM, Ted Mielczarek wrote:
> On Wed, May 9, 2018, at 1:11 PM, L. David Baron wrote:
> > > mozregression won't be able to bisect into inbound branches then, but I
> > > believe we've always been expiring build artifacts created from
> integration
> > > branches after a
On 2018-05-09 2:58 PM, Andrew Halberstadt wrote:
Going back to the original question, it looks like mozregression doesn't
use the builds that Nick wants to remove anyway. So regardless of our
retention policies, it looks like removing these builds would have no
impact on mozregression's effective
Going back to the original question, it looks like mozregression doesn't
use the builds that Nick wants to remove anyway. So regardless of our
retention policies, it looks like removing these builds would have no
impact on mozregression's effectiveness. Is that an accurate statement?
-Andrew
On W
On 2018-05-09 2:01 PM, Ted Mielczarek wrote:
It's useful for tracking down regressions no matter how old the
regression is; I pretty regularly see mozregression finding useful
data on bugs that regressed multiple years ago.
To be clear here--we still have an archive of nightly builds dating back
On Wed, May 9, 2018, at 1:11 PM, L. David Baron wrote:
> > mozregression won't be able to bisect into inbound branches then, but I
> > believe we've always been expiring build artifacts created from integration
> > branches after a few months in any case.
> >
> > My impression was that people use
On 5/9/18 12:11 PM, L. David Baron wrote:
It's useful for tracking down regressions no matter how old the
regression is; I pretty regularly see mozregression finding useful
data on bugs that regressed multiple years ago.
I want to agree with David -- I recall one incident in particular where
I
On Wednesday 2018-05-09 12:39 -0400, William Lachance wrote:
> On 2018-05-09 11:48 AM, Botond Ballo wrote:
> > > Good question. I checked and it seems that the answer is no (yay).
> > >
> > > For nightly builds in mozregression, we fetch stuff out of:
> > >
> > > https://archive.mozilla.org/pub/f
On 2018-05-09 11:48 AM, Botond Ballo wrote:
Good question. I checked and it seems that the answer is no (yay).
For nightly builds in mozregression, we fetch stuff out of:
https://archive.mozilla.org/pub/firefox/nightly/
For inbound builds, we've been using taskcluster for a while.
What about
On Wed, May 9, 2018 at 11:16 AM, William Lachance wrote:
> On 2018-05-09 4:59 AM, Xidorn Quan wrote:
>>
>> Would removing those files affect the ability of mozregression to locate
>> pushes of old regressions?
>
>
> Good question. I checked and it seems that the answer is no (yay).
>
> For nightly
On 2018-05-09 4:59 AM, Xidorn Quan wrote:
Would removing those files affect the ability of mozregression to locate pushes
of old regressions?
Good question. I checked and it seems that the answer is no (yay).
For nightly builds in mozregression, we fetch stuff out of:
https://archive.mozilla
Would removing those files affect the ability of mozregression to locate pushes
of old regressions?
- Xidorn
On Wed, May 9, 2018, at 4:49 PM, ntho...@mozilla.com wrote:
> We have approximately 400 TB of old files in the two directories
> firefox/tinderbox-builds and mobile/tinderbox-builds on
>
25 matches
Mail list logo
