Status

Tree Management Graveyard
TBPL
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: jhford, Assigned: philor)

Tracking

Trunk
x86
Mac OS X
Dependency tree / graph

Details

Attachments

(1 attachment)

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

6 years ago
jhford: what's the timeline for this?

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

Comment 2

6 years ago
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?
(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

6 years ago
(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.  :-)
(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.
(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

6 years ago
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?
not yet, I am working on getting that set up.

Comment 9

6 years ago
So I'd make this bug depend on the other one for enabling the actual builds.
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
(Assignee)

Comment 11

6 years ago
Created attachment 606438 [details] [diff] [review]
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.
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED
Attachment #606438 - Flags: review?(ehsan)
Attachment #606438 - Flags: feedback?(jhford)

Comment 12

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

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

Well, let's hope this works!
Attachment #606438 - Flags: review?(ehsan) → review+
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.
Attachment #606438 - Flags: feedback?(jhford) → feedback+
(Assignee)

Comment 14

6 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Updated

6 years ago
Depends on: 738891
Product: Webtools → Tree Management
Product: Tree Management → Tree Management Graveyard
You need to log in before you can comment on or make changes to this bug.