Closed
Bug 519229
Opened 15 years ago
Closed 14 years ago
purge_builds.py shouldn't count the current build directory as "used"
Categories
(Release Engineering :: General, defect, P2)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bhearsum, Assigned: coop)
Details
(Whiteboard: [automation][oldbugs])
Attachments
(2 files)
1.25 KB,
patch
|
bhearsum
:
review+
coop
:
checked-in+
|
Details | Diff | Splinter Review |
1.05 KB,
patch
|
bhearsum
:
review+
coop
:
checked-in+
|
Details | Diff | Splinter Review |
I've noticed that even after two builds in a row from the exact same builder happen on the same slave, sometimes purge_builds.py tries to clean up.
Assignee | ||
Comment 1•14 years ago
|
||
Mass move of bugs from Release Engineering:Future -> Release Engineering. See http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
Priority: -- → P3
Assignee | ||
Updated•14 years ago
|
Whiteboard: [automation]
Comment 2•14 years ago
|
||
I'm really tempted to wontfix this. Is it breaking anything?
Reporter | ||
Comment 3•14 years ago
|
||
It makes us clobber more build directories than necessary, which probably hurts our build times overall.
Updated•14 years ago
|
Assignee: nobody → armenzg
Status: NEW → ASSIGNED
Priority: P3 → P4
Comment 4•14 years ago
|
||
bhearsum is this still wanted?
Reporter | ||
Comment 5•14 years ago
|
||
Yes, this still causes unnecessary clobbers.
Updated•14 years ago
|
Whiteboard: [automation] → [automation][oldbugs]
Assignee | ||
Comment 6•14 years ago
|
||
(In reply to comment #3) > It makes us clobber more build directories than necessary, which probably hurts > our build times overall. Trying to make sure I understand...the change you're proposing is to consider free space as reported free space + current build dir used space? Is calculating the used space of the current build dir for every build faster or slower than just clobbering?
Reporter | ||
Comment 7•14 years ago
|
||
(In reply to comment #6) > (In reply to comment #3) > > It makes us clobber more build directories than necessary, which probably hurts > > our build times overall. > > Trying to make sure I understand...the change you're proposing is to consider > free space as reported free space + current build dir used space? For the purposes of purge_builds.py, yeah. > Is calculating the used space of the current build dir for every build faster > or slower than just clobbering? Not sure, but full clobbers on 64-bit Mac are significantly longer than a dep build. We could skip calculating the disk space of the current directory in any case where we already have enough free space without taking it into account. If you want to argue that it's not worth the effort I'm not going to push back.
Assignee | ||
Comment 8•14 years ago
|
||
(In reply to comment #7) > We could skip calculating the disk space of the current directory in any case > where we already have enough free space without taking it into account. Bingo! I think that makes this bug much easier to implement and worth pursuing. We'd just need to add a new flag to purge_builds.py to take the current dir as a special arg (which we can then check if necessary) rather than just adding it as another protected dir at the end of the list.
Updated•14 years ago
|
Priority: P4 → P5
Whiteboard: [automation][oldbugs] → [automation][oldbugs][triagefollowup]
Assignee | ||
Updated•14 years ago
|
Assignee: armenzg → coop
Status: ASSIGNED → NEW
OS: Mac OS X → All
Priority: P5 → P3
Hardware: x86 → All
Whiteboard: [automation][oldbugs][triagefollowup] → [automation][oldbugs]
Assignee | ||
Updated•14 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P2
Assignee | ||
Comment 9•14 years ago
|
||
I'd tried this a few ways with actually calculating the space we'd gain for purging cwd, but it was taking far too long to calculate the space used vs. just removing the dir. I figure if you don't have enough free space before the final dir purge (cwd) and you *still* don't after, you've got bigger problems anyway, so it's easier to just try that final delete and let the step fail if it's going to. I do skip over deleting the tools/ dir under the current dir. Because of our current order of operations, the tools/ dir gets cloned before the clobber happens. Maybe we want to fix up that logic too, but this patch avoids deleting the new clone. I'll need to make a follow-up patch to buildbotcustom to stop adding cwd to the skip list because this will make it redundant.
Attachment #502898 -
Flags: review?(bhearsum)
Reporter | ||
Comment 10•14 years ago
|
||
Comment on attachment 502898 [details] [diff] [review] Purge cwd after everything else, but only if we still need to Sounds great to me!
Attachment #502898 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 11•14 years ago
|
||
(In reply to comment #9) > I'll need to make a follow-up patch to buildbotcustom to stop adding cwd to the > skip list because this will make it redundant. ...and here it is.
Attachment #502904 -
Flags: review?(bhearsum)
Reporter | ||
Updated•14 years ago
|
Attachment #502904 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 12•14 years ago
|
||
Comment on attachment 502898 [details] [diff] [review] Purge cwd after everything else, but only if we still need to https://hg.mozilla.org/build/tools/rev/df1d119be141
Attachment #502898 -
Flags: checked-in+
Assignee | ||
Comment 13•14 years ago
|
||
Comment on attachment 502904 [details] [diff] [review] Stop passing cwd as a dir to be ignored https://hg.mozilla.org/build/buildbotcustom/rev/8344247b0811
Attachment #502904 -
Flags: checked-in+
Assignee | ||
Comment 14•14 years ago
|
||
At some point we'll need a reconfig to pick up the buildbotcustom change (landed), but it's very low priority and can easily be batched with other landings the next time someone needs to merge to production-0.8.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•