Closed Bug 694077 Opened 13 years ago Closed 13 years ago

add nightly builds to Birch

Categories

(Release Engineering :: General, defect, P3)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bear, Assigned: bear)

References

Details

(Whiteboard: [configs])

Attachments

(4 files, 1 obsolete file)

      No description provided.
Assignee: nobody → bear
Priority: -- → P3
Whiteboard: [configs]
per email from dougt, he would also like nightly updates for these nightly builds.

bear: do you have an ETA for doug?
per discussion with johnath, jp, we need updates for nightly birch builds too.
Blocks: 694987
Attachment #567459 - Flags: review?(bhearsum)
Attachment #567460 - Flags: review?(bear) → review+
Attachment #567460 - Flags: checked-in+
Flags: needs-reconfig?
Attachment #567459 - Flags: review?(bhearsum) → review+
Attachment #567459 - Flags: checked-in+
Depends on: 695057
20111017 reconfig has landed this change
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Flags: needs-reconfig?
We're not uploading snippets for the Android birch nightlies, need to figure out why.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The snippet is created but we upload it to the wrong place:
command: ssh -l ffxbld -i /home/cltbld/.ssh/ffxbld_dsa aus2-staging.mozilla.org mkdir -p fake/Android_arm-eabi-gcc3/20111019040213/en-US

For comparison, a mozilla-central nightly does:
command: ssh -l ffxbld -i /home/cltbld/.ssh/ffxbld_dsa aus2-staging.mozilla.org mkdir -p /opt/aus2/incoming/2/Fennec/mozilla-central/Android_arm-eabi-gcc3/20111020031025/en-US

I think the problem is in config.py's |for branch in ACTIVE_PROJECT_BRANCHES:| loop, where we don't set aus2_mobile_base_upload_dir and aus2_mobile_base_upload_dir_l10n.
Attachment #568599 - Flags: review?(nrthomas)
Comment on attachment 568599 [details] [diff] [review]
helps if you tell buildbot where to upload the snippets

We should do the equivalent of this for mobile instead:
http://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla/config.py#l1620
Attachment #568599 - Flags: review?(nrthomas) → review-
made the aus2_mobile* setting generic by moving it into config.py as suggested
Attachment #568599 - Attachment is obsolete: true
Attachment #568657 - Flags: review?(bhearsum)
Attachment #568658 - Flags: review?(bhearsum)
So, I copied in the snippets that were uploaded this morning to the proper directory, and discovered that updates _still_ weren't happening. That's because attachment #567459 [details] [diff] [review] only updated the AUS config for Firefox, not Fennec (oops!). Catlee is fixing that.
Attachment #568657 - Flags: review?(bhearsum) → review+
Comment on attachment 568658 [details] [diff] [review]
now with updates for fennec!

Once this patch makes it to production, we should have nightly updates for birch instantly.
Attachment #568658 - Flags: review?(bhearsum) → review+
Depends on: 696392
Attachment #568658 - Flags: checked-in+
Comment on attachment 568657 [details] [diff] [review]
helps if you tell buildbot where to upload the snippets

committed changeset 4923:c8d6207c6184
Attachment #568657 - Flags: checked-in+
Comment on attachment 568657 [details] [diff] [review]
helps if you tell buildbot where to upload the snippets

A reconfig that included this happened today.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Thanks, guys! Am I right in assuming that downloading the apk currently in 

http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-birch-android/

will get the job done forevermore? (I'm concluding from comment 13 that there's not any kind of "after tomorrow's nightly this should work" business?)
(PS - Is it wrong of me to want a new nightly spun just so I can see it work?)
relaying what I said just now in IRC:

while we have cleared up the issue with update generation, a client side bug exists that is causing the wrong update channel to be generated

when that bug is fixed and you want a nightly to test, just ping me and i'll trigger one
bhearsum and I just sidebar'd with dougt in Toronto. Doug says he has a workaround that would work for en-US, but mostly needs to sync up with Rob Strong about the update process. We rely on locale information specified in a file which, on mobile, is within the apk, and doug would rather just check the locale programmatically rather than go through I/O operations to get get it from disk.
The locale file was added in a rush when I first took over app update due to it previously using the locale pref which could be changed by the user, extensions, etc. which would then cause app update to download a different update locale. evil EVIL! ;)

So, the locale could be added to the platform.ini and then added to XULAppInfo or friend.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: