Closed siegesmund closed 7 years ago
Hey @siegesmund, can you share your serverless.yml
?
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.
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.
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?
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
tofunctionObject.package.artifact
in the Openwhisk plugin allows the function to be deployed.