627604 - jetpack SDK now lives in a new repo: need to update buildsteps

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Brian Warner [:warner :bwarner]]

Due to a problem with the git-to-hg bridge (in bug 618838), we had to move the jetpack repo to a new home (in bug 623787). It now lives at http://hg.mozilla.org/projects/addon-sdk .

From the log at http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1295535232.1295535952.3246.gz&fulltext=1 it appears that the jetpack-testing step is still pulling code from the old repo (i.e. mozillalabs/jetpack-sdk). That repo hasn't been updated since mid-december. Unfortunately in retrospect, we decided to leave the old repo in place (and merely update its description) rather than delete it entirely, so the buildbot has been getting stale code rather than a clean error.

So we need to update the buildsteps to pull from the right place. I'm hopeful that this will improve the breakage noted by bug 570251 or bug 627070, but I don't know for sure.

Comment 1

[Brian Warner [:warner :bwarner]]

From one log I'm looking at (http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1295996877.1295997041.28526.gz), it looks like the buildstep is downloading and unpacking a tarball from http://hg.mozilla.org/labs/jetpack-sdk/archive/tip.tar.bz2 rather than doing an "hg clone" or "hg pull". So I don't think that this fix will be made any more difficult by the fact that the new repo's history is unrelated to the old repo (such that 'hg pull' into an existing tree would get confused).

OTOH, it appears that the URL is written into a build artifact, the file "jetpack/jetpack-location.txt" inside a generated tests .zip bundle. I don't know enough about our build process to figure out what needs to be modified to change the contents of this file.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: new jetpack repo location

So bug 589005 shows where the jetpack location gets set - my patch updates that location - but I'll need someone with mozilla-central commit privileges to land this.

Comment 3

[cmtalbert]

Landed http://hg.mozilla.org/mozilla-central/rev/464f3a23aa4e

Comment 4

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to comment #3)
> Landed http://hg.mozilla.org/mozilla-central/rev/464f3a23aa4e

Thanks Clint!

Leaving this open to track tests reporting green, and then unhiding them on tinderbox/tbpl.

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: backout of fc842735184a - re-enables jetpack for all opt/debug platforms

we need these back on now that the new repo is in use.

Comment 6

[Aki Sasaki (not active)]

Attachment: change the directory name

Comment 7

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Now that the patch has landed, and builds generated with that patch, all Jetpack tests are consistently burning red, with an error during/immediatelyafter extracting the bz2 file.

...
addon-sdk-66de8008a38a/static-files/syntaxhighlighter/styles/shThemeDefault.css
program finished with exit code 1
elapsedTime=0.973526
TinderboxPrint: jetpack<br/>
Unknown Error: command finished with exit code: 1
=== Output ended ===
======== BuildStep ended ========
...



Aki posted a patch for one missed reference to the old repo. Unknown why we do not get the "SDK_DIR is either missing or invalid." error message in the logs. This needs further investigation. 

Note: as these builds are currently hidden, this is wasting compute cycles, but is *not* closing the tree.

Comment 8

[Phil Ringnalda (:philor)]

(In reply to comment #4)
> Leaving this open to track tests reporting green, and then unhiding them on
> tinderbox/tbpl.

They are not hidden because they were red, they were red because they were hidden, and they were hidden because the decision reached in the public discussion in m.d.planning was that it wasn't acceptable to have the tip of a separate repository close mozilla-central, so we were going to wait until jetpack had something stable that we could import into mozilla-central, and then have visible tests that ran against that. Are we now talking about unhiding them in the same state that was previously unacceptable because we privately reverted that decision, or just because we forgot why they were hidden?

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: re-enable jetpack on m-c as well as adding to try suites

per discussion in IRC I am now adding it to the try suites for quicker iterations by developers in fix but leaving out win7 for both (a builder will be loaned out for troublshooting 'hung slave' issues).

Comment 10

[Armen [:armenzg]]

For the win7 situation please refer to this log:
https://bugzilla.mozilla.org/show_bug.cgi?id=627070#c0

Comment 11

[Brian Warner [:warner :bwarner]]

incidentally, the current Linux failure is probably bug 628112

Comment 12

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to comment #8)
> (In reply to comment #4)
> > Leaving this open to track tests reporting green, and then unhiding them on
> > tinderbox/tbpl.
> 
> They are not hidden because they were red, they were red because they were
> hidden, and they were hidden because the decision reached in the public
> discussion in m.d.planning was that it wasn't acceptable to have the tip of a
> separate repository close mozilla-central, so we were going to wait until
> jetpack had something stable that we could import into mozilla-central, and
> then have visible tests that ran against that. Are we now talking about
> unhiding them in the same state that was previously unacceptable because we
> privately reverted that decision, or just because we forgot why they were
> hidden?

Moving this comment to bug#629263, which is tracking test failures, and tracking displaying results for this test suite on TBPL. Thats a better place to discus this topic.

Comment 13

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

per irc with lsblakk, this work of switching to use new jetpack repo is all done here, so ok to close.