Closed Bug 908698 Opened 11 years ago Closed 11 years ago

Gaia unit tests: /bin/bash: ./xulrunner-sdk-26/bin/run-mozilla.sh: No such file or directory

Categories

(Firefox OS Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jgriffin, Assigned: jgriffin)

References

Details

Attachments

(1 file, 2 obsolete files)

Gaia unit tests are currently red on TBPL with the following error:

08:43:52     INFO - Copy/paste: make
08:43:52     INFO - Using env: {'DEBUG': '1', 'DESKTOP': '0', 'NOFTU': '1', 'USE_LOCAL_XULRUNNER_SDK': '1'}
08:43:53     INFO -  test -d profile-debug || mkdir -p profile-debug
08:43:53     INFO -  run-js-command  applications-data
08:43:53     INFO -  /bin/bash: ./xulrunner-sdk-26/bin/run-mozilla.sh: No such file or directory
08:43:53     INFO -  make: *** [applications-data] Error 127

This is happening because gaia now wants xulrunner-sdk-26 for make, but the slaves are downloading an earlier version.
Gaia now expects the xulrunner-sdk to be in a xulrunner-sdk-26 folder.  I might also need to upload a new xulrunner-sdk to tooltool, but we can see if this is enough to fix the tests, first.
Attachment #794716 - Flags: review?(ahalberstadt)
Assignee: nobody → jgriffin
So, this is due to bug 906316, sorry about that.

Jonathan, if you merely run "make" the correct xulrunner should be downloaded and extracted in the correct directory. Or maybe the TBPL VM don't have access to Internet ?
Ah I get it, it's because of "USE_LOCAL_XULRUNNER_SDK". Maybe we should go on and use the old "xulrunner-sdk" directory if USE_LOCAL_XULRUNNER_SDK is set. Or maybe even use a path set by USE_LOCAL_XULRUNNER_SDK ? What do you think ?
(In reply to Julien Wajsberg [:julienw] from comment #2)
> So, this is due to bug 906316, sorry about that.
> 
> Jonathan, if you merely run "make" the correct xulrunner should be
> downloaded and extracted in the correct directory. Or maybe the TBPL VM
> don't have access to Internet ?

Yes, it isn't that easy in buildbot; the build slaves cannot download the xulrunner-sdk from the internet, so we set USE_LOCAL_XULRUNNER_SDK=1 and pre-download it before invoking 'make'.  Currently, we're downloading an old version, and putting it in the wrong location, so this pre-seeding isn't working.
> Or maybe even use a path set by USE_LOCAL_XULRUNNER_SDK ? What do you think ?

This option would definitely make the automation more robust in the future.
Do you know if there are other users of USE_LOCAL_XULRUNNER_SDK ?
No idea!  If we're concerned about breaking someone else, we could introduce a different env variable.
Comment on attachment 794716 [details] [diff] [review]
Use xulrunner-sdk-26 folder in gaia-unit script,

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

Any idea why they changed this?
Attachment #794716 - Flags: review?(ahalberstadt) → review+
I have a very simple patch to change the Makefile, using the existing XULRUNNER_DIRECTORY that you'll be able to set from the commandline.

You'll keep the existing USE_LOCAL_XULRUNNER_SDK but just specify XULRUNNER_DIRECTORY too.

Will upload in 5 minutes.
Attached patch patch v1 (obsolete) — Splinter Review
Now we can define XULRUNNER_DIRECTORY from the command-line. If not defined, it
will use the default xulrunner-sdk-26.
---
 Makefile |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Attachment #794727 - Flags: review?(yurenju.mozilla)
(In reply to Andrew Halberstadt [:ahal] from comment #8)

> Any idea why they changed this?

Because on different branches we might need different xulrunner runtimes (and we do these days), and the current way of doing it was redownloading Xulrunner when changing branch. Not good. :)
So with this patch you'll need to define:

* XULRUNNER_DIRECTORY=<relative path>
* USE_LOCAL_XULRUNNER_SDK=1

Would you need to use an absolute path ? If yes the change is bigger (we need to remove all "./" at the start of all paths) and would need to be well tested on all platforms, which I can't do right now.
No, we can use a relative path (which I assume is relative to the gaia repo?)
New version of the patch which goes along with julienw's change to gaia in comment #12
Attachment #794748 - Flags: review?(ahalberstadt)
Attachment #794716 - Attachment is obsolete: true
Comment on attachment 794748 [details] [diff] [review]
Use xulrunner-sdk-26 folder in gaia-unit script,

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

Lgtm.
Attachment #794748 - Flags: review?(ahalberstadt) → review+
Attachment #794727 - Flags: review?(yurenju.mozilla) → review+
Depends on: 908984
I made a travis run using the PR at https://github.com/mozilla-b2g/gaia/pull/11736.

No evidence of problems related to this patch so landing the gaia part.

master: cb1ef14cfd641ed2d6ba99402af57f28ae35dbc2
We'll likely need bug 908984 too, otherwise the email sub-build won't work with another xulrunner directory.
Blocks: 906316
(In reply to Julien Wajsberg [:julienw] from comment #6)
> Do you know if there are other users of USE_LOCAL_XULRUNNER_SDK ?

FWIW My team does use this too. Your patch helped. Thanks Julien!
https://hg.mozilla.org/build/mozharness/rev/7b73036ccfb1

Will see if this works ok on cedar.
As I said, we'll need bug 908984 too, otherwise email build won't work, but I want to test it thoroughly on various environments before merging. Probably tomorrow.
master: 2a74e6be62895a020659c44b5c7c8eb68b3695f5, reverted cb1ef14cfd641ed2d6ba99402af57f28ae35dbc2.
The reverted patch will be integrated in the new patch for bug 906316, but we'll still need the patch for TBPL, so I'm not closing this bug.
Attachment #794727 - Attachment is obsolete: true
Use xulrunner_sdk v26 in gaia_unit:  https://hg.mozilla.org/build/mozharness/rev/9c8e61a7e7aa
Gaia unit tests are running again (but orange...that's for another bug) on TBPL.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: