Closed
Bug 467721
Opened 16 years ago
Closed 16 years ago
the l10n factory should run its steps inside of the "build" folder
Categories
(Release Engineering :: General, defect, P1)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: armenzg, Assigned: coop)
Details
Attachments
(1 file, 1 obsolete file)
3.47 KB,
patch
|
nthomas
:
review+
coop
:
checked-in+
|
Details | Diff | Splinter Review |
The "rm -rf *-nightly/build" that was added to other nightly factories removes the "build" folder inside every *-nightly folders on a slave In the l10n steps on the RepackFactory, "mozilla-central" repo and the "l10n-central" repo are checked out into "." instead of "build" therefore not being deleted by other nightly builds runs. Fixing this will ensure that when other nightly builds start we will be sure that anything checked out by the l10n steps gets cleaned out so we 1) keep the disk usage low and will ensure that 2) we start the l10n process from a fresh point every night CURRENTLY . ./build <- This guy is removed ./mozilla-central <- This guy is *not* being removed because it is not inside of the previous folder ./l10n-central IT SHOULD BE: . ./build/mozilla-central <- This guy and the next should now be removed since they live inside of "*-nightly/build" ./build/l10n-central Side note, the l10n nightly runs will not be deleting themselves (or other branches' l10n nightly runs) since their remove step is slightly different from other normal nightly runs: 'find .. -maxdepth 2 -type d -path "*-nightly/build" -not -path "*-l10n-nightly/build" -print -exec rm -rf {} \;'
Assignee | ||
Updated•16 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P1
Assignee | ||
Comment 1•16 years ago
|
||
This will also entail removing the existing checkouts of l10n-central and mozilla-central from all the slaves that have already checked them out in the wrong place or we'll end up compounding the problem.
Assignee | ||
Comment 2•16 years ago
|
||
Attachment #352407 -
Flags: review?(nthomas)
Assignee | ||
Comment 3•16 years ago
|
||
Also checks to make sure the upload dir exists before trying to remove it.
Attachment #352407 -
Attachment is obsolete: true
Attachment #352411 -
Flags: review?(nthomas)
Attachment #352407 -
Flags: review?(nthomas)
Updated•16 years ago
|
Attachment #352411 -
Flags: review?(nthomas) → review+
Comment 4•16 years ago
|
||
Comment on attachment 352411 [details] [diff] [review] Run l10n build steps in the build/ subdir to allow for proper cleanup, v2. Looks fine to me.
Assignee | ||
Comment 5•16 years ago
|
||
Ran fine in staging. I'll add this to the list of things to push during the downtime tomorrow.
Comment 6•16 years ago
|
||
Reading the patch this will remove and re-clone mozilla-central for each locale, i.e., some 70 times per platform?
Assignee | ||
Comment 7•16 years ago
|
||
Not ideal, I know, but space is really at a premium on these slaves.
Reporter | ||
Comment 8•16 years ago
|
||
(In reply to comment #6) > Reading the patch this will remove and re-clone mozilla-central for each > locale, i.e., some 70 times per platform? > To make it clear (if I have not lost track of things) Each locale's run *won't* be removing what the previous locale has checked out. 'find .. -maxdepth 2 -type d -path "*-nightly/build" -not -path "*-l10n-nightly/build" -print -exec rm -rf {} \;' The only thing that each new locale's run will be deleting is the nightly folders of other nightly runs and the 'build/'+BRANCH+'/dist/upload' Other nightly runs will after this patch be able to remove what the l10n nightly runs have checked out.
Assignee | ||
Updated•16 years ago
|
Attachment #352411 -
Flags: checked‑in+
Assignee | ||
Comment 9•16 years ago
|
||
Comment on attachment 352411 [details] [diff] [review] Run l10n build steps in the build/ subdir to allow for proper cleanup, v2. Checking in factory.py; /cvsroot/mozilla/tools/buildbotcustom/process/factory.py,v <-- factory.py new revision: 1.57; previous revision: 1.56 done
Assignee | ||
Updated•16 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 16 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
•