Hi Belinda and welcome to the mailing list :-) Your repo looks like a great start, I can help create a new repo under openwhisk, this "deploy" package can be a package for such similar actions.
One thing I notice, is that the wskdeploy action should also support a simple git repo directory structure with a manifest file at the root and no runtimes sub folders -- Carlos On Mon, Oct 16, 2017 at 3:55 PM Belinda M Vennam <[email protected]> wrote: > Hi everyone, > > My name is Belinda Vennam, and I have been building on Priti's manifest > work towards enabling "one click deployment" of some applications on > Openwhisk, and would like to share that work with the community through a > new deploy package. > > The action within the deploy package would enable users to deploy from a > github repo, as long as the repo contains a valid manifest.yaml file, and > correct directory structure. > > The deploy package would be available in the whisk.system namespace, as > /whisk.system/deploy. > > The assets would be deployed based on repos with the appropriate > structure, and a defining manifest. The invocation of the deploy action > would look like: > wsk action invoke /whisk.system/deploy/wskdeploy -p repo > https://github.com/my-repo-name -p manifestPath "runtimes/node" > > The wskdeploy action within the deploy package will deploy from a github > repo, but other similar actions can be added to the deploy package in the > future. > > You can find the current project (as a work in progress) in my own repo > here: > https://github.com/beemarie/openwhisk-package-deploy > > Looking forward to hearing any input and looking forward to contributing > to the OpenWhisk project! > > Thanks, > Belinda Vennam > > > > > > From: "Priti Desai" <[email protected]> > To: [email protected] > Date: 06/26/2017 02:28 PM > Subject: Introducing incubator-package-build > > > > > > 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 > index.js > package.json > cd actions/my-action > npm install --production > zip -rq action.zip * > wsk action create my-action --kind nodejs:6 action.zip > > 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". > > "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 > incubator-package-build: > > ls actions/my-action/ > index.js > package.json > cd actions/my-action > zip -rq action.zip * > wsk action invoke nodejs-build --blocking --param action_name my-action > --param action_data `cat action.zip | base64` > > Pros: > > 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 README.md 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. > > Cons: > > 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 > common. > 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! > > Cheers > Priti > > P.S.: > > https://github.com/apache/incubator-openwhisk/issues/2243 > https://github.com/pritidesai/incubator-package-build > https://github.com/pritidesai/incubator-package-build/blob/master/README.md > > > > > >
