1132225 - Move gaia builds into their own job(s) and do not attempt to build gaia on each platform

Status: RESOLVED WONTFIX

(Taskcluster :: General, defect)

Description

[James Lal [:lightsofapollo]]

(Note: I have no idea what the right component is here)

Right now we build and rebuild gaia in many places (in the emulator builds / desktop / many tests / etc...) Often times these builds are identical or nearly so but add significant overhead in both complexity and time (2-5 min per build depending how you count). Additionally running these steps requires checking out and updating a gaia clone which adds additional vcs load and time.

The proposal here is to build gaia on a single job (run by taskcluster) [or maybe a set of jobs] and publish these on index (example: https://tools.taskcluster.net/index/artifacts/#buildbot.revisions.8b93ad254a01.try/buildbot.revisions.8b93ad254a01.try.linux-debug) individual builds can choose to include this profile or more likely download one at the time the user/test framework needs it.

Generally this is a clear win as we also get easy to access historical builds of gaia the potential downside is how we effect the ease of use of some of our desktop products.

Comment 1

[James Lal [:lightsofapollo]]

@stas can you weigh in on the impact here for localizers? The difference here is the we will no longer ship b2g-desktop (or emulators / etc...) with a gaia build (double clicking on the app will simply not work without some changes) and can we potentially help the transition here in any way?

Comment 2

[James Lal [:lightsofapollo]]

Does this effect Mulet at all? I suspect the only effect this has it would be easier to find an existing gaia build if you happen to need one (like for the simulator?)

For the simulator I vaguely remember there is another thing which is creating the builds and profile is this effected either?

Comment 3

[James Lal [:lightsofapollo]]

+ catlee (we discussed via vidyo)

Per my recollection we can use these same gaia builds if needed on other platforms (windows / osx) too but we may need to poll for their presence on index prior to starting the tests the implication here is if TC goes down and stops creating these builds it will _break_ other platforms which rely on gaia builds.

Longer term we can mitigate this with the buildbot bridge we are discussing by making this a deterministic part of the garph.

Comment 4

[Alexandre Poirot [:ochameau]]

(In reply to James Lal [:lightsofapollo] from comment #2)
> Does this effect Mulet at all? I suspect the only effect this has it would
> be easier to find an existing gaia build if you happen to need one (like for
> the simulator?)

Mulet doesn't ship any gaia profile and it is fine continuing _not_ doing that. Smaller package and gaia developers most likely want to test it against _their_ gaia profile

> For the simulator I vaguely remember there is another thing which is
> creating the builds and profile is this effected either?

This time it is different, we are targetting app developers who want a fully working desktop OS.
We need a gaia profile.
Simulator is built during b2g desktop build on mozilla-central.
(note that once mulet is ready, simulator will be based on top of mulet)
Concretely, it happens here:
  http://mxr.mozilla.org/mozilla-central/source/b2g/simulator/build_xpi.py
We have this small python bash script that craft the simulator addon with b2g runtime and gaia profile.
It is being called from here:
  http://mxr.mozilla.org/mozilla-central/source/b2g/installer/Makefile.in#124
And rely on mozconfig having GAIADIR=/path/to/gaia/profile and FXOS_SIMULATOR=1

I don't care how, what, when, we do build the addon, as soon as we still build it.
I can give a hand porting build_xpi features to any other build env.

Comment 5

[James Lal [:lightsofapollo]]

>Simulator is built during b2g desktop build on mozilla-central.
>(note that once mulet is ready, simulator will be based on top of mulet)

So it seems like we can apply the same treatment (build it in it's own job only on linux) here but build the gaia profile specifically for the simulator. This has the same set of benefits as above... I don't remember exactly the state of the caching we have in the gaia but we could potentially just build the simulator profile in the same job if it is fast.

This would mean we simply pass a url (or directory?) to the xpi script and it would finish the rest of the customizations from the given gaia profile...

Any objections? (Also we probably want to add a check or two per commit to make sure we don't break the simulator prior to merge to mc!)

Comment 6

[Alexandre Poirot [:ochameau]]

(In reply to James Lal [:lightsofapollo] from comment #5)
> So it seems like we can apply the same treatment (build it in it's own job

Sounds good.

> only on linux)

Sounds *not* gound. Simulators are released on all platforms linux32, linux64, macos and windows.

> This has the same set of benefits as above... I don't remember
> exactly the state of the caching we have in the gaia but we could
> potentially just build the simulator profile in the same job if it is fast.
> 
> This would mean we simply pass a url (or directory?) to the xpi script and
> it would finish the rest of the customizations from the given gaia profile...

Sounds good.

Comment 7

[Staś Małolepszy :stas]

(In reply to James Lal [:lightsofapollo] from comment #1)
> @stas can you weigh in on the impact here for localizers? The difference
> here is the we will no longer ship b2g-desktop (or emulators / etc...) with
> a gaia build (double clicking on the app will simply not work without some
> changes) and can we potentially help the transition here in any way?

I'd like to raise this question in dev-l10n to gauge localizers' reaction.  My educated guess is that by now most localizers use the Simulator and/or an actual device.  There's not much need for having b2g-desktop builds around.

Would we continue to build the Simulator in a way that bundles it with a Gaia profile?  I think comment 5 suggest it would be possible via the xpi script, but I'd like to make sure I understand correctly.

Comment 8

[James Lal [:lightsofapollo]]

> Sounds *not* gound. Simulators are released on all platforms linux32, linux64, macos and windows.

(Just to record what we discussed on irc) The gaia profile itself is cross platform and therefore will only be built on linux we will have simulator builds for all platforms.

(So mulet/simulator story is solved here now)

Comment 9

[James Lal [:lightsofapollo]]

>I'd like to raise this question in dev-l10n to gauge localizers' reaction.  My educated guess is that by >now most localizers use the Simulator and/or an actual device.  There's not much need for having >b2g-desktop builds around.

That would solve many problems... we want to kill b2g-desktop as soon as we can.

>Would we continue to build the Simulator in a way that bundles it with a Gaia profile?  I think comment 5 >suggest it would be possible via the xpi script, but I'd like to make sure I understand correctly.

The internals of when/how we build the profile would be different (but faster) but the end result will be the same. 

@stas: So are localizers mostly on the simulator at this point ? Can we raise the issue of dropping b2g-desktop now and see who still needs help moving over?

Comment 10

[Staś Małolepszy :stas]

(In reply to James Lal [:lightsofapollo] from comment #9)

> @stas: So are localizers mostly on the simulator at this point ? Can we
> raise the issue of dropping b2g-desktop now and see who still needs help
> moving over?

I started a thread in dev-l10n to hear from the localizers:

https://groups.google.com/forum/#!topic/mozilla.dev.l10n/IPETHJ22Ttk

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Hey James,

I just have one question regrading this bug. For testing purpose, we would still need to ensure the Gaia build script do not break under the 3 platforms. I ask Ricky to create Gb & Gbu tests on 3 OSes but I am not sure if that's in conflict with what you want to do here.

Please needinfo me or :rickychien if that's the case.

Comment 12

[James Lal [:lightsofapollo]]

So this would remove running gaia builds on any other platform but linux (the byproduct is cross platform) if your aim is to ensure the gaia build works for local users (infra never needs to run on anything other then linux for our mozilla only purposes) then the gaia build tests should be run on various platforms you care about.

If your aim by running the tests is to make sure we don't break infra when we make changes to the build system this is no longer an issues after this work is complete.

Any questions?

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to James Lal [:lightsofapollo] from comment #12)
> So this would remove running gaia builds on any other platform but linux
> (the byproduct is cross platform) if your aim is to ensure the gaia build
> works for local users (infra never needs to run on anything other then linux
> for our mozilla only purposes) then the gaia build tests should be run on
> various platforms you care about.
> 
> If your aim by running the tests is to make sure we don't break infra when
> we make changes to the build system this is no longer an issues after this
> work is complete.
> 
> Any questions?

I see. I however think we should (1; bug 1131471) enabling Gbu/Gu tests on all platforms first *then* (2; this bug) stop building Gaia in Mac/Windows tasks, or we will lost Mac/Windows coverage in between.

Make sense?

Comment 14

[James Lal [:lightsofapollo]]

Okay so at minimum we can start this process for the emulators and phone builds (which is a nice win time wise) but I am curious what the motivation for the support of windows is in particular are we saying we support a development workflow of _gaia_ on windows?

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to James Lal [:lightsofapollo] from comment #14)
> Okay so at minimum we can start this process for the emulators and phone
> builds (which is a nice win time wise) but I am curious what the motivation
> for the support of windows is in particular are we saying we support a
> development workflow of _gaia_ on windows?

Yes, that's we are told -- we need to support development workflow of Gaia on Windows, for the community.

Comment 16

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Tim Guan-tin Chien [:timdream] (slow response; please ni?) from comment #15)
> Yes, that's we are told -- we need to support development workflow of Gaia
> on Windows, for the community.

This actually raised an interesting question: do think think maintaining Windows support worthy of the cost? Or do you think we should just ask Windows users to get a Ubuntu in a VM?

Comment 17

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I should probably revise comment 13 -- bug 1131471 has nothing to do with enabling Gb & Gbn on Windows/Mac and doing so might be non-trivial, involving more support on Windows than we currently do.

Our CI currently guarantees the default |make| always work on Mac and Windows (runs in B2G Desktop Mac|Windows respectively, and marked as "B") and nothing else.