Files are accumulated in /builds/updates/firefox-$version each time we build a new $version, and in /home/ftp/pub/firefox/nightly/ every time we run the automation. We might be able to fix the latter by with (something like) rsync --delete staging-build-console:/home/ftp/pub/firefox/nightly/ \ staging-prometheus-vm:/home/ftp/pub/fiefox/nightly/ after cleaning up the console. Similar might work for /builds/updates/ too.
I was about to try this out when I noticed that there's already a step like this in the 1.8 staging master.cfg :). It seems to work fine, so here's a patch to add it to trunk staging, too.
Attachment #294489 - Flags: review?(rhelmer)
Attachment #294489 - Flags: review?(rhelmer) → review+
Checking in staging-1.9/master.cfg; /cvsroot/mozilla/tools/buildbot-configs/automation/staging-1.9/master.cfg,v <-- master.cfg new revision: 1.4; previous revision: 1.3 done
Attachment #294489 - Attachment description: sync external staging area on trunk automation → [checked in] sync external staging area on trunk automation
I keep coming by this bug and thinking it can be closed...then I see the /builds/updates part...is there a reason we can't just add an extra rsync step and be done with it?
Hm, isn't this fixed now? What am I missing here?
/builds/updates isn't completely taken care of yet. It works on 1.9 because the Buildbot master also runs the Updates, but on 1.8 it is run on the Linux slave. /builds/updates never gets synced (only /home/ftp does). /builds/updates gets clobbered as part of clean_stage; we could simply add a second rsync step to cleanup /builds/updates on the Linux slave.
This is fixed by the slavePrestage builder. /builds/updates/ gets clubbered on every run.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.