Closed Bug 772681 Opened 12 years ago Closed 12 years ago

need to replace SDK python packager implementation with a javascript implementation

Categories

(Cloud Services :: Operations: Marketplace, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: canuckistani, Assigned: oremj)

References

Details

The SDK team has re-implemented add-on packaging in JS, with the eventual goal of packaging add-ons in-browser.

We have two potential options to run the js packaging code on the server:

1. install xulrunner on the servers, this requires no code changes
2. implement a way to run our JS code using node.js

We'd like to land js packaging soon but feel we need to develop a plan with the builder team and IT to ensure that builder continues to work as expected.
cc'ing the relevant parties
Blocks: cfx.js
When do you need this and can you point us to docs for installing xulrunner?
It will depend on your distro, but you might have it packaged?
Otherwise, you can manually install binaries from ftp:
  http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/14.0.1/runtimes/

I think that the harder part is to ensure that dependencies are installed. For example, to run, firefox requires an X server, even from the console. An Xvfb server would be enough. Then there might be some other dependencies like media libraries.

There isn't any particular deadline but we would like to give it a try soon, as we are waiting for this before landing a big patch already r+ in Jetpack.
Note that we may even install xulrunner by ourself in a user directory,
but I don't think that we can install necessary dependencies like this.
Is anyone currently working on a way to run our JS code using node.js?
(In reply to Jeremy Orem [:oremj] from comment #5)
> Is anyone currently working on a way to run our JS code using node.js?

No. I'm the one to do this, but I'd like to avoid this as it would be only usefull as a temporary workaround for addon builder purpose. The plan is to stop building addons on server side, so that they will be built by Firefox itself via an addon.
If we can make it work on xulrunner we will avoid unecessary work.

(If you have more experiences with xpcshell it may work on that too.)
How temporary is this going to be? Closer to a few weeks or several months?

I'm not familiar with xulrunner or xpcshell. What's the advantage of one over the other?
I'd expect it to be more like several months, I'd really like to see this being done in Q3, but as it doesn't only depends on me I can't promise it.
xpcshell is a bit more lightweight as it only execute one given JS file, instead of an application package with a manifest file, applications folder layout and all.
But it might be a bit harder to use as it seems to be removed from xulrunner releases :(

I've heard that b2g team asked to get xpcshel being built standalone, but it doesn't seem to be done yet.
It looks like RHEL 6 contains xulrunner 10.0.6. Will this version be adequate?
I gave it a try and it seems to work perfectly fine on 10.
Does xulrunner need to be installed on the web nodes or just celery?
Assignee: server-ops → oremj
If CELERY_ALWAYS_EAGER is true, then cfx is executed on the web node, and the response just waits on it. If eager is false, then cfx executes on the celery node.

So, at least on celery, and possibly on the webnode if it's ever desired to set it back to eager.
To close out this bug I just need to install that xulrunner package on celery then?
:oremj, it sounds like it to me - Sean seems to allude to this when he says 'if it's ever desired to set it back to eager.'

Sean, please clarify that in the *current configuration*, CELERY_ALWAYS_EAGER is set to FALSE. Also, it would be great to know more about the trade-off between the 2 ways to run this ( it sounds like setting it to true is for development? )
I don't have access to the server settings_local.py, so I can't say what it's set to currently. We do set it to eager for development, but we typically have eager off in production. However, we have set eager to true in production before, when celery was having issues.
CELERY_ALWAYS_EAGER = False
Alexandre, if I make xulrunner available to the application, can I close out this bug?
we would need some testing to be done by addon builder team.
i don't really know if we should do this in this bug or in a followup one.
Let's close this bug with that done - Alex can you log a new bug for the builder team testing? Unsure who to assign it to right now, probably Piotr.
xulrunner has been installed. Let me know if you need anything else.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Jeremy, Is there X/Xvfb or any X server on these nodes?
It is a mandatory piece in order to be able to run xulrunner.
Component: Server Operations: AMO Operations → Operations: Marketplace
Product: mozilla.org → Mozilla Services
You need to log in before you can comment on or make changes to this bug.