735954 - support b2g builds

Status: RESOLVED FIXED

(Tree Management Graveyard :: TBPL, defect)

Description

[John Ford [:jhford] CET/CEST Berlin Time]

We are going to be building b2g on branches very soon.  TBPL should understand it.  builder names will follow the patterns:

b2g <build platform> <branch> [build|nightly]

with an example of 

b2g fedora16-x86_64 mozilla-central build
b2g fedora16-x86_64 mozilla-central nightly

At some point, I could see us having 'b2g' and 'b2g-debug' if we start doing regular and debug builds.  Log upload locations tbd

Comment 1

[Laura Thomson :laura]

jhford: what's the timeline for this?

philor, mstange, rhelmer: can one of you take this on?

Comment 2

[(no longer active)]

This will be a bit more tricky than other types of trees, since this is going to point to the github b2g repo I assume?

Comment 3

[[:fabrice] Fabrice Desré]

(In reply to Ehsan Akhgari [:ehsan] from comment #2)
> This will be a bit more tricky than other types of trees, since this is
> going to point to the github b2g repo I assume?

Ehasn, details on the build toolchain are in bug 719491

Comment 4

[(no longer active)]

(In reply to Fabrice Desré [:fabrice] from comment #3)
> (In reply to Ehsan Akhgari [:ehsan] from comment #2)
> > This will be a bit more tricky than other types of trees, since this is
> > going to point to the github b2g repo I assume?
> 
> Ehasn, details on the build toolchain are in bug 719491

Thanks.  Just to make sure that I'm understanding the relevant details for this bug correctly, the code will come from mozilla-central and a custom buildbot branch is going to be set up for this.  Does anybody know the name of the buildbot branch?  I can write the patch in a few seconds with that information.  :-)

Comment 5

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Ehsan Akhgari [:ehsan] from comment #2)
> This will be a bit more tricky than other types of trees, since this is
> going to point to the github b2g repo I assume?

Nope, they are built from hg.m.o repos.  These are similar to firefox builds except that:
1) no tests for now
2) nothing is uploaded at the end except for logs
3) logs are uploaded /pub/mozilla.org/b2g instead of /pub/mozilla.org/firefox


These aren't build of the whole 'b2g' deliverable, instead they are here to test that no one breaks b2g's gecko component by landing mozilla-central changes.

Comment 6

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Ehsan Akhgari [:ehsan] from comment #4)
> Thanks.  Just to make sure that I'm understanding the relevant details for
> this bug correctly, the code will come from mozilla-central and a custom
> buildbot branch is going to be set up for this.  Does anybody know the name
> of the buildbot branch?  I can write the patch in a few seconds with that
> information.  :-)

This won't be a different buildbot branch, it'll be done on existing branches similar to how mobile builds work today.

Comment 7

[(no longer active)]

OK, so b2g will be a new platform in the TBPL sense.  We usually look at the logs to see what types of tokens and magic keywords we should be looking for in order to detect platforms and build types.  Are there existing logs available from buildbot that I can use?

Comment 8

[John Ford [:jhford] CET/CEST Berlin Time]

not yet, I am working on getting that set up.

Comment 9

[(no longer active)]

So I'd make this bug depend on the other one for enabling the actual builds.

Comment 10

[John Ford [:jhford] CET/CEST Berlin Time]

already is :)  I'll have staging stuff up and running very soon, so I should be able to get you logs before the builds go live in production

Comment 11

[Phil Ringnalda (:philor)]

Attachment: As a Linux64 job

We don't need any more information about the builds than what's in comment 0, what we need is a prediction of the future.

Calling it a new OS, giving it a line of its own, would make sense if we believe that in the very near future, it will have packaged tests which run on mozilla-central (or, I guess, if we think we're too dumb to hover over the red letter to figure out why one Linux64 build is green, but another that says "B2g" instead of "B" is red).

If instead we believe that sometime in the not so near future, it'll maybe have packaged tests running on mozilla-central, or maybe it'll wind up like Jetpack, with a single defensive job on mozilla-central and then a tree of its own where it runs its tests, then we should instead make it just another flavor of Linux build, which will show up on the Linux64 line, and save the vertical space until and unless we have to use it. I'm betting that way, so I wrote that patch first.

Comment 12

[(no longer active)]

Comment on attachment 606438 [details] [diff] [review]
As a Linux64 job

Review of attachment 606438 [details] [diff] [review]:
-----------------------------------------------------------------

Well, let's hope this works!

Comment 13

[John Ford [:jhford] CET/CEST Berlin Time]

Comment on attachment 606438 [details] [diff] [review]
As a Linux64 job

I don't know how TBPL works internally, but this looks reasonable. It doesn't matter to me whether this shows up as Linux64 or a new OS, so long as it turns the tree red on failure.

I think we want to have tests running as well as builds, but that's not something we're doing right now.

Comment 14

[Phil Ringnalda (:philor)]

We pretty much have to hope it works, there isn't any decent alternative. We don't actually need logs - if you look at http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-linuxqt/1332048313/mozilla-inbound-linuxqt-build2004.txt.gz, an actual log, you won't see what we work with, "Linux QT mozilla-inbound build," anywhere in it.

What we need is "a builds-4hr.js.gz with it in it," which we aren't going to get in any reasonable way. If the job starts out only run on a twig where nobody cares what tbpl winds up looking like at first, we could look first and patch later. Or if not, we could take the painful approach of saying "start running it, we'll either eat the confusion (which in this case would be two "B"s for Linux64) or hide it on every tree, then we'll fix ourselves, then in a few days when prod gets updated we'll either stop being confusing or we'll unhide it."

But what we've been doing for quite a while now is saying "tell me exactly what the buildername will look like, and don't you lie to me" and going with that, and mostly it's worked out fine.

http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/00a5555607ef