serverless / serverless-openwhisk

Adds Apache OpenWhisk support to the Serverless Framework!
http://openwhisk.org/
MIT License
143 stars 46 forks source link

Deploying binary functions individually fails #79

Closed siegesmund closed 7 years ago

siegesmund commented 7 years ago

sls deploy -f foo fails with a compiled binary. sls deploy deploys all functions, including the binary, successfully.

It fails at serverless-openwhisk/compile/functions/runtimes/base.js.

Specifically, in

getArtifactPath(functionObject) { return this.serverless.service.package.individually ? functionObject.artifact : this.serverless.service.package.artifact; },

functionObject.artifact is undefined, causing getArtifactZip to fail and crash the deployment. In the Serverless Framework, the artifact appears to be stored at functionObject.package.artifact.

Changing functionObject.artifact to functionObject.package.artifact in the Openwhisk plugin allows the function to be deployed.

jthomas commented 7 years ago

Hey @siegesmund, can you share your serverless.yml?

siegesmund commented 7 years ago

This is an example. One deviation from your example functions is that runtimes are defined on a per-function basis, something that works with other cloud provider plugins.

service: foobar

provider:
  name: openwhisk

functions:
  # Returns golang binary version
  version:
    runtime: binary
    handler: functions/version/main

plugins:
  - serverless-openwhisk

To get around the error, I've forked and modified the serverless-openwhisk plugin and am testing it locally. So far, it deploys both binary and node.js functions both individually and on a per-service basis. I haven't tried Swift, Python, etc.

siegesmund commented 7 years ago

I have created a repo which recreates the problem on my machine. Again, the problem is:

sls deploy >> works sis deploy -f test >> fails

I encountered this bug while writing an openwhisk go plugin which allows a developer to manage the full Go action lifecycle from the sls command line, a significant workflow improvement that already exists for fully supported languages on AWS and Azure. I haven't published it yet, however, pending some clarity on this issue.

jthomas commented 7 years ago

Great, thanks for the additional context. I've reproduced the problem locally as well. PR you raised looks fine but can you update the tests so the CI passes?