openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Priti Desai" <>
Subject Introducing incubator-package-build
Date Fri, 23 Jun 2017 18:27:28 GMT

Hi everyone,

I have been working with wskdeploy tool to create manifests for some
Node.js applications so that we can enable "one click deployment" of those
applications. I was able to create manifest file for a few of them but had
difficulty with others. The problem is when application includes action,
which has dependencies on node modules that might not be available in
OpenWhisk Node.js runtime containers. An OpenWhisk runtime container does
have number of built-in packages but some modules that I was using are not
available. For example, I have action that relies on the MySQL database
service and uses mysql client npm package to drive sql interactions. This
MySQL package is not available in OpenWhisk runtime container. To resolve
such imports, I am forced to install mysql module locally and upload it in
a ZIP file along with the action file, such as:

ls actions/my-action
cd actions/my-action
npm install --production
zip -rq *
wsk action create my-action --kind nodejs:6

While I was working on this kind problem, I came across an open issue on
OpenWhisk and with the help of other OpenWhisk developers decided to give
it shot.  I wrote an automation to build Node.js application inside of
OpenWhisk instead of installing npm modules locally and packaging them with
action files. Here is the link to prototype of the automation

"incubator-package-build" automates action creation process by installing
node modules specified in 'package.json' file and creating an action for
you. Here is the improved workflow of creating action with

ls actions/my-action/
cd actions/my-action
zip -rq *
wsk action invoke nodejs-build --blocking --param action_name my-action
--param action_data `cat | base64`


1. The biggest advantage of this automation is it can be run by any user
and does not need any admin privileges on OpenWhisk to install node
modules. You can follow for step-by-step instructions on how to
deploy such automation and create actions using this automation.
2. This automation is one time deployment. All it does is creates an action
"nodejs-build" in your namespace. Now this nodejs-build can be invoked any
number of times just like any other action. And nodejs-build can create any
number of actions importing any node modules.
3. nodejs-build allows us to update an action or introduce new imports.
Once we are done updating the action, we can rerun nodejs-build the same
way as before and it will update the action to reflect our changes.


1. The node modules are installed for one action cannot be packaged or
reused by other actions. nodejs-build installs all packages specified in
package.json irrespective of whether multiple actions have some modules in
2. nodejs-build takes base64 encoded compressed data which forces us to
create a zip file out of the action files.
3. This automation is limited to Node.js runtime. I am sure we are facing
similar issues with other runtimes including Swift, Java, and Python.

Note: It adds some latency to the first execution of nodejs-build as it
fetches docker image from docker hub. Subsequent execution of nodejs-build
is not affected.

This is just the first step towards addressing this issue. I would like to
improve this automation to address all the points listed in "Cons" section
but would like your feedback and comments before working on next version of
this automation.

Please help me by providing your inputs.

Thanks in advance!


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message