Closed Bug 454594 Opened 16 years ago Closed 16 years ago

need a makefile target that can upload files via ssh

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: ted)

References

Details

(Whiteboard: [hg-automation])

Attachments

(2 files, 3 obsolete files)

This will probably end up replacing the MozillaStageUpload stuff in buildbotcustom, and most certainly is needed for various parts of release automation.
Whiteboard: [hg-automation]
Blocks: 452472
Blocks: 433930
I vote for this (uploading l10n repackages will benefit)
I can hack into this once you have something
Blocks: 454261
Depends on: 455578
Attached patch basic wip (obsolete) — Splinter Review
This adds a |make upload| target in toolkit/mozapps/installer, that will upload the package (and installer on win32), controlled by environment variables. It also adds (for Firefox), a top-level target to call into that target.
Attached patch mostly complete (obsolete) — Splinter Review
This is similar to the previous, but it also allows you to upload files to different subdirectories, so we can put installers etc in the right place.

This doesn't handle uploading full MARs. bhearsum: do you think that should happen in this same target, or in a different target (maybe in tools/update-packaging?)
Attachment #339268 - Attachment is obsolete: true
So I realized that preserving the installer path is not what we want for nightly builds:
http://mavra.perilith.com/~luser/latest-teds-builds/

The installer winds up in installer/sea. I think for now, we'll explicitly override PKG_INST_PATH, setting it to empty for the nightly builds when we make installer/upload. Once we get this in production, I'd like to just make PKG_INST_PATH empty by default. I don't see any reason the installer can't just wind up in $DIST like the package.
Actually, moving the default path to be more sensical was something I had in mind when moving those paths into package-name.mk :)
We just need to be sure that all buildbots using trunk are converted to that new code first, including SeaMonkey and Thunderbird ones, as the current buildbot stuff hardcodes install/sea.
We also should be able to handle langpack upload in some similar style.
No longer blocks: 454261
Comment on attachment 341150 [details] [diff] [review]
mostly complete

We'll deal with uploading the MARs in a separate bug. This patch adds the upload script, and the upload target packager.mk (and browser/build.mk). It will upload the build package (and installer on Windows), controlled via environment vars.
Attachment #341150 - Flags: review?(benjamin)
Attachment #341150 - Flags: review?(benjamin) → review-
Comment on attachment 341150 [details] [diff] [review]
mostly complete

non-trivial things should be in python, we agree ;-)
Attached patch with upload.py instead (obsolete) — Splinter Review
Much nicer.
Attachment #341150 - Attachment is obsolete: true
Attachment #347839 - Flags: review?(benjamin)
Attachment #347839 - Flags: review?(benjamin) → review+
Comment on attachment 347839 [details] [diff] [review]
with upload.py instead

subprocess.check_call is not available in python 2.4, it was introduced in 2.5. As noted on IRC, it's easy to emulate, see client.py for code. r=me with that
Ok, I hoisted that block out of client.py into build/util.py, and used it from both files. (And verified that client.py still works.)
Attachment #347839 - Attachment is obsolete: true
Attachment #347962 - Flags: review+
Pushed: http://hg.mozilla.org/mozilla-central/rev/f3d9ccfea0a3
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Small follow-up. Apparently my testing isn't thorough enough, as I failed to notice that msys would also mangle POST_UPLOAD_CMD if it's an absolute path.
Attachment #347973 - Flags: review?(benjamin)
Attachment #347973 - Flags: review?(benjamin) → review+
Blocks: 464707
Depends on: 468124
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.