Closed Bug 861426 Opened 7 years ago Closed 6 years ago

Set up nightly-1.0.1 update channel

Categories

(Release Engineering :: General, defect, P2)

x86_64
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: catlee, Assigned: catlee)

References

Details

(Whiteboard: [b2g])

Attachments

(6 files, 1 obsolete file)

Nightly builds on mozilla-b2g18_v1_0_1 need to be built with a new channel ('v1.0.1-nightly'?)

The b2g update server needs to handle these updates as well.
Attachment #738057 - Flags: review?(aki)
Comment on attachment 738057 [details] [diff] [review]
add --update-channel cmdline option

Yeah, we'll probably need to get more config items out of nested lists/dictionaries as we want to override them via commandline or a 2nd config file.  Upload servers come to mind, for staging.
Attachment #738057 - Flags: review?(aki) → review+
Duplicate of this bug: 862391
Attachment #738057 - Flags: checked-in+
Blocks: 860355
Attachment #738077 - Flags: review?(aki) → review+
Depends on: 862526
Merged the mozharness patch to production.
(In reply to Aki Sasaki [:aki] from comment #5)
> Merged the mozharness patch to production.

so is this resolved yet?   can it be tested now on 1.0.1 branches for all supported devices?
No, it's not ready yet.
After lots of discussion and testing, I've decided to change the update URL slightly.

Our nightly device builds will query URLs like http://.../unagi/1.0.1/nightly
Dep builds will have the update channel set to 'default', and so won't get updates. This matches how Firefox Desktop and Mobile builds are done.

I need to make corresponding changes to b2g_config.py, and possibly configs/b2g/releng*.py to enable updates for other devices/branches.
Attachment #738077 - Attachment is obsolete: true
Attachment #745148 - Flags: review?(aki)
Comment on attachment 745148 [details] [diff] [review]
Add nightly_update_channel config option; make sure we're updating the URL in the update.xml properly

If we ever get confused by any of the query_* logic (why we're falling through to 'default' or w/e), we can add some self.debug() or self.info() statements.
Attachment #745148 - Flags: review?(aki) → review+
this is like releng-otoro.py, with updates enabled (like releng-beta.py)
Attachment #745371 - Flags: review?(aki)
this will enable nightly updates for inari on all branches
we can enable updates for other devices once this works
Attachment #745372 - Flags: review?(aki)
Attachment #745372 - Flags: review?(aki) → review+
Attachment #745371 - Flags: review?(aki) → review+
Attachment #745148 - Flags: checked-in+
Attachment #745371 - Flags: checked-in+
Attachment #745372 - Flags: checked-in+
in production
https://tbpl.mozilla.org/php/getParsedLog.php?id=22640747&tree=Mozilla-B2g18

IOError: Can't find b2g/releng-private-updates.py in ['.', '/builds/slave/b2g_m-b18_inari_ntly-000000000/scripts/scripts/../configs', '/builds/slave/b2g_m-b18_inari_ntly-000000000/scripts/scripts/../../configs']!
Inari builds should be getting updates on mozilla-b2g18 and mozilla-b2g18_v1_0_1 now.
On Inari 1.0.1 device;
verified OTA fix:  20130506230205 -> 20130507070205 is successful.
Attachment #746716 - Flags: review?(nthomas)
Comment on attachment 746716 [details] [diff] [review]
enable updates for leo, hamachi

This only turns on hamachi updates for 1.0.1, is that expected ? In b2g_config.py, leo is included in the BRANCHES definition for mozilla-b2g18_v1_0_1 but a loop deletes it later.
Attachment #746716 - Flags: review?(nthomas) → review+
Poorly phrased comment there - On 1.0.1, this only turns on updates for hamachi. Does both for m-b2g18.
Comment on attachment 746714 [details] [diff] [review]
update releng-beta.py config to set publish_channel to nightly

It looks like the xml fo;es will have .../beta/... for the mar url, via base_url and nightly_update_channel. r+ if wsgi means that still works ok when published to /nightly/.
Attachment #746714 - Flags: review?(nthomas) → review+
Erm, BTW, if the channel names we end up here are in any way substantially different from what we had before, we need to clear up with the Socorro team on how we can make crash-stats with those. Their system is extremely closely tied to our usual scheme of channel names, and any substantial difference will break them with multiple weeks or months of work needed to get anything to work with them.
Depends on: 869905
As a side note, we currently have set up the rule that whatever releases are being put in the wild for Firefox OS should have "release-<vendor>" set as release channels so that we can do something useful with crash data (I wonder how well this is communicated atm though). If this changes that assumption, we need to communicate this.
Attachment #746716 - Flags: checked-in+
leo/hamachi configs deployed in production
(In reply to Nick Thomas [:nthomas] from comment #20)
> Comment on attachment 746714 [details] [diff] [review]
> update releng-beta.py config to set publish_channel to nightly
> 
> It looks like the xml fo;es will have .../beta/... for the mar url, via
> base_url and nightly_update_channel. r+ if wsgi means that still works ok
> when published to /nightly/.

so I think the mar will still exist at the original location, so this should still work...or am I missing something?
Attachment #746714 - Flags: checked-in+
This issue is resolved for:
Unagi v1.1.0 Mozilla RIL
Build ID: 20130508070204-> Build ID: 20130509070205
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/84f4c17f1605
Gaia: 4e7d63a83508caa391c4db164c3f68422d9ca5b6
and
Inari v1.0.1 Mozilla RIL
Build ID: 20130508070205 -> Build ID: 20130509070209
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/b0b2b5cfdc5b
Gaia: 30ad443fbe5363a7381c19c6bf9d6ca49228fb8b
Product: mozilla.org → Release Engineering
I think this was done long ago...
Closing.  Please reopen if there's something left to do.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.