Figure out retention of flame tinderbox-builds

RESOLVED FIXED

Status

Release Engineering
Other
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: nthomas, Assigned: nthomas)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Like bug 969767, but for flame. Do we know what we want to do yet Clint ?
Flags: needinfo?(ctalbert)
See Also: → bug 969767

Comment 1

3 years ago
Ideally, I want to keep them all. :-)

The flame is going to be our reference device for the next year.  At the very least we should keep the 12-18 weeks as this will give us the ability to bisect across the lifetime of the 2.0 release using these builds.

As we saw with 1.3, 1.3t, and 1.4 the releases live long after the 12 week "release cycle". So, we need to keep at least 12 weeks worth of builds. That's our minimum.

Also, now that we have a phone with a sane flashing story, we might be able to do some build on the fly and flash bisection tools so that we don't necessarily have to keep the tinderbox builds around. But it will take a few weeks to get that effort together.

So right now, we want at least the 12 weeks of flame device builds kept. More if you can get it. :-)

Thanks
Flags: needinfo?(ctalbert)
Duplicate of this bug: 1046801
Created attachment 8465782 [details] [diff] [review]
[svn] cron changes

In order of importance:
* add 12 week retention for all flame builds. This is much simpler than white/backlisting branches, and the contribution from older gaia and project branches is tiny compared to b2g-i and m-i anyway
* limit 12 week retention for hamachi to mozilla-b2g30_v1_4 branch
* stop deleting crashsymbols & logs, they are a small contribution 
(< 5%) compared to device images and gecko/gaia tarballs
* while we're here, removes cron on empty mnt/pvt_builds/pvt/mozilla.org/b2g/tinderbox-builds

Projecting from current disk usage we will use an additional 2.5T of space, which is within the current allocation.
Attachment #8465782 - Flags: review?(bugspam.Callek)
Comment on attachment 8465782 [details] [diff] [review]
[svn] cron changes

Review of attachment 8465782 [details] [diff] [review]:
-----------------------------------------------------------------

pretty much just stamping, but based on your explanation this all sounds great
Attachment #8465782 - Flags: review?(bugspam.Callek) → review+
Comment on attachment 8465782 [details] [diff] [review]
[svn] cron changes

Committed revision 91279.
Attachment #8465782 - Flags: checked-in+
Leaving open for verification early next week.
Created attachment 8466839 [details] [diff] [review]
[svn] Partial revert

The change from 21 to 7 days for emulator builds was not intended, reverted:
Committed revision 91348.
Attachment #8466839 - Flags: checked-in+
Verified working. I expedited the cleanup of dirs like b2g-inbound-hamachi*, the previous style of removing crash symbols and logs meant they had mtimes quite a bit later than when the builds were produced.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Comment on attachment 8466839 [details] [diff] [review]
[svn] Partial revert

Turns out I misread my earlier patch and had never changed it in the first place (pub vs pvt), and we're running filling up the disk now. I've backed it out.

Committed revision 91741.
Attachment #8466839 - Flags: checked-in+ → checked-in-
You need to log in before you can comment on or make changes to this bug.