649375 - please add jetpack branch to tbpl

Status: VERIFIED FIXED

(Tree Management Graveyard :: TBPL, defect)

Comment 1

[Mounir Lamouri (:mounir)]

Where can i found the repo?

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

http://hg.mozilla.org/projects/addon-sdk/

(totally not obvious, is it?)

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

note that the tinderbox is http://tinderbox.mozilla.org/showbuilds.cgi?tree=Jetpack

Comment 4

[Mounir Lamouri (:mounir)]

Attachment: Add jetpack

Comment 5

[(no longer active)]

Comment on attachment 525443 [details] [diff] [review]
Add jetpack

Do we really want to call this "Jetpack"?  "Addon-SDK" is a much more meaningful name.

Comment 6

[Phil Ringnalda (:philor)]

If we added support for treeInfo.prettierName, we could correctly spell JägerMonkey, too.

Comment 7

[Mounir Lamouri (:mounir)]

Attachment: Add jetpack as "Addon-SDK"

Comment 8

[Mounir Lamouri (:mounir)]

Pushed:
https://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/549f2548accc

Comment 9

[Myk Melez [:myk] [@mykmelez]]

What else needs to be done to make this happen?  The following URL still doesn't work:

http://tbpl.mozilla.org/?tree=Addon-SDK

And Addon-SDK is not listed in this list of available trees:

http://tbpl.mozilla.org/wrongtree.html?tree=Addon-SDK

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

I believe this still needs to be deployed.

Comment 11

[Mounir Lamouri (:mounir)]

We usually mark tbpl bugs fixed when they are fixed (AFAIK).

Comment 12

[Mounir Lamouri (:mounir)]

By "when they are fixed" I meant "when they are pushed".

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

If the jetpack tbpl page does not exist yet, because this hasn't been deployed yet, then how is this fixed?  Do Myk or I need to file another bug?  Can the summary of this bug be altered to reflect that there is still not a resolving page at http://tbpl.mozilla.org/?tree=Addon-SDK ?


as Philor pointed out: https://bugzilla.mozilla.org/show_bug.cgi?id=651524#c11 landing doesn't mean "working".

Comment 14

[Phil Ringnalda (:philor)]

I filed your other bug, bug 652455, but aren't you totally familiar with the style of resolving bugs when they land in the repo, rather than when they are deployed to production? I thought that was what releng did all the time, RESO FIXED and I go look, wonder why I don't see it, and then remember that means "landed on tip, which will be merged to production some time in the future, maybe next Thursday, maybe by accident before then, or when we have some emergency that calls for a quick merge and reconfig." tbpl works the same way, except with no schedule at all, and only two people who can deploy, and only one of them is around at all right now.

Comment 15

[Phil Ringnalda (:philor)]

I'm not sure you'll entirely like the result of having this deployed, though: http://dev.philringnalda.com/tbpl-tip/ and then choose Addon-SDK, you go to http://dev.philringnalda.com/tbpl-tip/?treeName=Addon-SDK which has the content of Firefox, decide to URL-hack and go to http://dev.philringnalda.com/tbpl-tip/?tree=Jetpack and you get the pushlog, but no tinderbox. So Reopened is the right state, but because it's broken and thus will get in the way of anything else being deployed, not because it's not deployed.

Comment 16

[Phil Ringnalda (:philor)]

Backed out in http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/9655e42fd839

Comment 17

[Lukas Blakk [:lsblakk] use ?needinfo]

I thought that was what releng did all the time, RESO
> FIXED and I go look, wonder why I don't see it, and then remember that means
> "landed on tip, which will be merged to production some time in the future,
> maybe next Thursday, maybe by accident before then, or when we have some
> emergency that calls for a quick merge and reconfig." 

While I understand the frustration regarding the current tbpl deployment issues (and thank you for filing a bug on that), I don't agree that the Releng SOP is to close our bugs as fixed until we've verified that the landing in production has occurred and the desired results are in place.  If that is not the case, you are always welcome to re-open bugs as that would mean they have been closed prematurely.

Comment 18

[Phil Ringnalda (:philor)]

The first attachment wouldn't have worked either, because we associate builds with pushes by looking for something matching /http:\/\/hg.mozilla.org\/([^"]*)\/rev\/([0-9a-f]{12})/ in the tinderbox json, which gets there by buildbot doing a TinderboxPrint step, and when the Jetpack tree gets triggered (I presume by polling http://hg.mozilla.org/projects/addon-sdk/), it downloads whatever is in http://hg.mozilla.org/projects/addon-sdk/archive/tip.tar.bz2 at the time the slave fetches it, and uses it without TinderboxPrinting what it was, and grovels around in nightly/latest-mozilla-central/ to pick a Firefox build to run against, and uses whichever it gets without TinderboxPrinting what it was, so not only do we have no addon-sdk rev to use to match builds with pushes, but someone looking at results has no m-c rev to tell them what they were run against (though the latter is not our problem, only a problem for people trying to make sense of failures).

Comment 19

[Phil Ringnalda (:philor)]

(http://dev.philringnalda.com/tbpl/?tree=Jetpack if you want to watch the first patch have no idea how to associate runs with pushes, bug 652491 for getting the TinderboxPrints.)

Comment 20

[Markus Stange [:mstange]]

It looks like this tree is only present on Tinderbox, because I don't see any entries with category:"addon-sdk" in http://build.mozilla.org/builds/builds-4hr.js.gz and I don't see any logs on ftp.mozilla.org. Is the plan to keep it that way?

Comment 21

[Markus Stange [:mstange]]

I relanded the patch:
http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/751ca393e04a

Sorry for dropping the ball here.

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

So actually - we don't have revisions because jetpack-poller builds are run via a ScriptFactory that runs a script which downloads and tests with urls that are passed in, there is no cloning from hg from which to get a revision.  The addonsdk is grabbed with a config setting that looks for the tip of the repo specified (eg. hg.mozilla.org/projects/addon-sdk/archive/tip.tar.bz2) and then the executable is pulled from ftp based on the same config file setting for the base url, and then looking for the right file extension (.dmg, .zip, .tar.bz2) per platform as passed in from the automation.

So.  To get the hg revisions I could print (in the running of the script, and thus to the logs of these runs) based on the .txt file which is also in the ftp_url to get the revision for m-c (or branch used, if aurora for example) and then the revision for the addon-sdk is discoverable once the archive.tar.bz2 is untarred (it's part of the dir name).

If I update run_jetpack.py to print out these two pieces of information they will be in jetpack-$platform logs and is there a way to then grab that for tbpl purposes?

for configs see: http://hg.mozilla.org/build/buildbot-configs/file/f56bf2ed364d/mozilla-tests/config.py#l468

Comment 23

[Lukas Blakk [:lsblakk] use ?needinfo]

I think I've answered my own question - adjusting http://mxr.mozilla.org/build/source/buildbotcustom/steps/unittest.py#157 to do additional TinderboxPrint based on what in the log (ie: adding a branch and addonsdk rev print line) should get us what we need. I'll start this today.

Comment 24

[Lukas Blakk [:lsblakk] use ?needinfo]

Ok the tinderbox has printed revs of both the m-c build its using as well as the sdk rev being pulled.  Hopefully we can get tbpl now?

Comment 25

[Phil Ringnalda (:philor)]

http://tbpl.mozilla.org/?tree=Jetpack

Comment 26

[Myk Melez [:myk] [@mykmelez]]

I can has tbpl, and it is teh awesome.