Closed Bug 1164212 Opened 5 years ago Closed 4 years ago

Create a new build class with Gaia built with |DOGFOOD=1|

Categories

(Taskcluster :: General, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: drs, Assigned: wcosta, NeedInfo)

References

Details

(Whiteboard: [spark])

Attachments

(1 file, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #1164194 +++

To support bug 1160491, we'll have to build a new class of Gaia build with the |DOGFOOD=1| env var set while building.

Thus, we'll have these classes of builds:

* nightly
* nightly-debug
* nightly-eng
* dogfood

Dogfood builds should point to the "dogfood" update channel. This channel will be built from master/m-c like all other builds, and receive updates roughly every week, after QA has signed off on these updates.

We need to discuss what class the "dogfood" class will be based on. More to come on that.
I think that, other than the update channel and env var, this will look just like the "nightly", e.g. "user" class, but I'm not sure. Fabrice, will the developer mode toggle work on non-rooted devices?

If not, we can't base the "dogfood" class on the "nightly" class. But then none of the other classes look good. "nightly-debug" is slow because Gecko is built with debug enabled. "eng" has a lot of extra cruft such as testing that we don't need.

I'm not sure, but we might also have a "nightly-userdebug" class. I think that might have gone away, though. We could always re-add that back, if needed. It might not be a perfect fit, though.
Flags: needinfo?(fabrice)
(In reply to Doug Sherk (:drs) (use needinfo?) from comment #0)
> Dogfood builds should point to the "dogfood" update channel. This channel
> will be built from master/m-c like all other builds, and receive updates
> roughly every week, after QA has signed off on these updates.

Regardless of what decision we come to from comment 1, we need to start getting this part in place. What do we need to do here? Here are the things that I can think of:

* Create the update channel itself so that Balrog serves it.
* Point it to the "dogfood" class of builds, just like how the "cypress" channel pointed to the "nightly" build class for a while.
* Give QA access to sign off on builds, so that we're only serving known-good builds of the "dogfood" class.

Wander, can you help us drive this? Would you like me to file bugs for these? Thanks.
Flags: needinfo?(wcosta)
(In reply to Doug Sherk (:drs) (use needinfo?) from comment #2)
> (In reply to Doug Sherk (:drs) (use needinfo?) from comment #0)
> > Dogfood builds should point to the "dogfood" update channel. This channel
> > will be built from master/m-c like all other builds, and receive updates
> > roughly every week, after QA has signed off on these updates.
> 
> Regardless of what decision we come to from comment 1, we need to start
> getting this part in place. What do we need to do here? Here are the things
> that I can think of:
> 
> * Create the update channel itself so that Balrog serves it.
> * Point it to the "dogfood" class of builds, just like how the "cypress"
> channel pointed to the "nightly" build class for a while.
> * Give QA access to sign off on builds, so that we're only serving
> known-good builds of the "dogfood" class.
> 
> Wander, can you help us drive this? Would you like me to file bugs for
> these? Thanks.

The "sign off" part here is a bit tricky, because we should only push data to OTA when QA acks the build. In mozharness, these operations are atomic. I have no idea in short term how to handle this. :catlee, any idea on that?

Also, TC currently doesn't support timely builds, but it seems that implementing that is not a problem. :lightsofapollo, can you confirm that?

Also TC
Flags: needinfo?(wcosta)
Flags: needinfo?(jlal)
Flags: needinfo?(catlee)
Ok, after talking to :catlee at IRC, I think what we need for dogfood is something like this: https://wiki.mozilla.org/ReleaseEngineering/How_To/Enable_or_Disable_Updates_on_Aurora

I am still checking how this exactly works and how we can automate it, but the general idea would be before a new build, we lock the latest update and generate a new one, and do the same on each weekly build.
You don't need root access to toggle root mode from the settings app (you need if you try to do it from the webIDE iirc).

But I wonder why we need a special build at all. Spark should just be a feature set, available in every nighly build in my opinion. Let's keep things simple.
Flags: needinfo?(fabrice)
(In reply to Fabrice Desré [:fabrice] from comment #5)
> You don't need root access to toggle root mode from the settings app (you
> need if you try to do it from the webIDE iirc).
> 
> But I wonder why we need a special build at all. Spark should just be a
> feature set, available in every nighly build in my opinion. Let's keep
> things simple.

We're going to be tracking dogfooders by IMEI. See bug 1161650. I don't think that this is a change that we can enable by default.

Based on what you said here, I think we can base the "dogfood" class on "user".
Depends on: 1088350
Assignee: nobody → wcosta
Status: NEW → ASSIGNED
I just had a chat with :bhearsum, and he gave me a much easier solution. Basically dogfood builds will be just as nightly, but pointing to a different update channel and of course done weekly. Whenever QA signs off an image, they can update the OTA release manually through balrog admin interface.
Attached file MozReview Request: bz://1164212/wcosta (obsolete) —
/r/9373 - Bug 1164212: Add spark dogfood config file.

Pull down this commit:

hg pull -r 21f1295054f5439308fa64bd3e55b7045b578f4e https://reviewboard-hg.mozilla.org/gecko/
Attachment #8610794 - Flags: review?(jlal)
Comment on attachment 8610794 [details]
MozReview Request: bz://1164212/wcosta

https://reviewboard.mozilla.org/r/9371/#review8125

Ship It!
Attachment #8610794 - Flags: review?(jlal) → review+
Flags: needinfo?(nhirata.bugzilla)
Attachment #8610794 - Flags: review+ → review?(jlal)
Comment on attachment 8610794 [details]
MozReview Request: bz://1164212/wcosta

/r/9373 - Bug 1164212: Add aries dogfood build task.

Pull down this commit:

hg pull -r 4e3640ffbf37490eeaa1d428945b48b026928d31 https://reviewboard-hg.mozilla.org/gecko/
I just realized I pushed mozharness patch to rb-hg/gecko and it was not refused...
No longer depends on: 1088350
Depends on: 1168910
Depends on: 1166745
No longer depends on: 1168910
Bug 1164212: Add aries dogfood build task.
Attachment #8612565 - Flags: review?(jlal)
Attachment #8610794 - Attachment is obsolete: true
Attachment #8610794 - Flags: review?(jlal)
Attachment #8612565 - Attachment is obsolete: true
Attachment #8612565 - Flags: review?(jlal)
Comment on attachment 8612565 [details]
MozReview Request: Bug 1164212: Add aries dogfood build task.

Bug 1164212: Add aries dogfood build task.
Attachment #8612565 - Attachment is obsolete: false
Attachment #8612565 - Flags: review?(garndt)
Comment on attachment 8612565 [details]
MozReview Request: Bug 1164212: Add aries dogfood build task.

https://reviewboard.mozilla.org/r/9373/#review8563

Ship It!
Attachment #8612565 - Flags: review?(garndt) → review+
https://hg.mozilla.org/mozilla-central/rev/1c25e4751327
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Landed and seen.  userdebug build flashed and verified.

Gaia-Rev        
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/9eae3880b132
Build-ID        20150602115822
Version         41.0a1
Device-Name     aries
FW-Release      4.4.2
FW-Incremental  eng.worker.20150602.114437
FW-Date         Tue Jun  2 11:44:45 UTC 2015
Bootloader      s1

Need to figure out why gaia isn't reporting right.  (separate issue)
Status: RESOLVED → VERIFIED
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(catlee)
Component: TaskCluster → General
Product: Testing → Taskcluster
Target Milestone: mozilla41 → ---
You need to log in before you can comment on or make changes to this bug.