1158367 - Check Spark apps directly into the Gaia repo

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect, P1)

Description

[Doug Sherk (:drs) (inactive)]

See this mailing list post for context: https://mail.google.com/mail/u/2/#sent/14ce9155f183bdfe

Key takeaways and what we're doing here: 
* We build apps and deploy them to their gh-pages branches manually.
    - Using the gh-pages branches kills two birds with one stone. We can use the apps as hosted apps from here, as well as use the branch name as the canonical pre-built branch for pulling into the Gaia build without requiring any extra tooling, such as bower, grunt, gulp, etc.
* We use the repo tool in the B2G repo to pull in the gh-pages versions of these repos. We'll avoid adding more tooling into Gaia to pull these in, for now.
* For the few hosted apps that we want to pull in from other vendors, we just clone these and pull them in using the B2G repo. They are just manifest files, for the most part.
* With all of this in place, it should be as simple as syncing from the B2G repo, then running |./build.sh gaia && ./flash.sh gaia|, to get these externally hosted apps onto a device.
    - This may mess up the workflow of Gaia developers working in the gaia repo, but they shouldn't be developing externally hosted apps from the gaia repo anyways.

Comment 1

[Doug Sherk (:drs) (inactive)]

Attachment: 0001-Add-Gaia-apps.patch

Needs cleanup.

Comment 2

[Dave Hylands [:dhylands]]

I had to remove all of the remotes except for fxos in order to get config.sh to work properly.

I did the following to test config.sh:

forked b2g-manifest repository.
checkout master
add the changes in the patch
push to your forked repository

Now run:

GITREPO=[e-mail]:dhylands/b2g-manifest.git ./config.sh aries

if it doesn't work, you need to repush your changes to your forked repository and test again (I use git commit --amend so that I don't stack up commits).

Comment 3

[Doug Sherk (:drs) (inactive)]

The mailing list thread that I referred to in comment 0 is actually this:
https://groups.google.com/forum/#!topic/mozilla.dev.gaia/nYBQCFhdexc

Comment 4

[Doug Sherk (:drs) (inactive)]

We probably don't need this, based on the conversation in bug 1159411.

Comment 5

[Doug Sherk (:drs) (inactive)]

Ok, we do still need this. We're going to check the Spark apps directly into the Gaia repo for now, inside the "spark" customizations folder. The apps will only be included in the build for the "spark" customization, since they're only going to be listed in Spark's 'apps.list'.

Comment 6

[Doug Sherk (:drs) (inactive)]

I'm going to write a script that we'll run every day which will mirror the gh-pages branches of each of the Spark apps to the Gaia repo.

Tim, any objections to this, and/or suggestions?

Comment 7

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

I am having trouble understand this bug v.s. bug 1159411. Are we taking both approaches? Dale said if bug 1159411 can work on certified apps we should use that and don't land things into Gaia.

Just like everyone, I do envisioned we should break up Gaia in to app repo in the long run, so the approach here is somewhat backward. However, if people feel we are not ready for that yet and we have a Spark deadline to meet, we would just have to do this and accept the fact of life.

Comment 8

[Doug Sherk (:drs) (inactive)]

Attachment: Check Spark apps directly into the Gaia repo.

(In reply to Tim Guan-tin Chien [:timdream] (slow response; please ni? to queue) from comment #7)
> I am having trouble understand this bug v.s. bug 1159411. Are we taking both
> approaches? Dale said if bug 1159411 can work on certified apps we should
> use that and don't land things into Gaia.

Unfortunately, bug 1159411's changes don't work for certified apps. The preload.py script which backs it turns apps that it preloads into hosted apps. We can't elevate hosted apps past privileged permissions.

> Just like everyone, I do envisioned we should break up Gaia in to app repo
> in the long run, so the approach here is somewhat backward. However, if
> people feel we are not ready for that yet and we have a Spark deadline to
> meet, we would just have to do this and accept the fact of life.

I agree, but I don't see an alternative here in the interim. We have less than a month to go for Spark, and no concrete plan to break the apps up.

Could you take a look at this patch? I plan on sticking it in a cron job that runs daily on a server.

Comment 9

[Doug Sherk (:drs) (inactive)]

https://github.com/fxos/spark/commit/8fe2cc0c9ee5e6cf064626d0e3fae5d6b9e8fc11

Thanks, I'll be starting the daily cron job once bug 1159457 lands.

Comment 10

[Doug Sherk (:drs) (inactive)]

Actually, I'll leave this open until the cron job starts, and the apps are actually checked in.

Comment 11

[Dale Harvey (:daleharvey)]

> Unfortunately, bug 1159411's changes don't work for certified apps. The 
> preload.py script which backs it turns apps that it preloads into hosted apps. 
> We can't elevate hosted apps past privileged permissions

I dont believe that is true, preload.py will pull down application.zip if it sees it (https://github.com/mozilla-b2g/gaia/blob/master/tools/preload.py#L260), at the very least the irc client definitely works via preload.py. I said hackerplace wouldnt because we havent enabled web components yet afaik

Going to check the other applications to see what may or may not be causing them to break

Comment 12

[Doug Sherk (:drs) (inactive)]

Spark apps checked into Gaia:
https://github.com/mozilla-b2g/gaia/commit/ef8bc8baadfc6334593d713c3667a639d857e441

Comment 13

[Doug Sherk (:drs) (inactive)]

(In reply to Dale Harvey (:daleharvey) from comment #11)
> I dont believe that is true, preload.py will pull down application.zip if it
> sees it
> (https://github.com/mozilla-b2g/gaia/blob/master/tools/preload.py#L260), at
> the very least the irc client definitely works via preload.py. I said
> hackerplace wouldnt because we havent enabled web components yet afaik
> 
> Going to check the other applications to see what may or may not be causing
> them to break

Dale and I discussed this on IRC. The IRC app isn't a certified app. Also, all certified apps automatically have web components activated for them. Thus, if web components aren't enabled for an app, then the app must not be certified. Thus, we can conclude that any app with web components disabled isn't a certified app, and we can't preload it.