Fatal error when trying to deploy single-functions

[AndrewFarley]

FYI: This is with the latest code from master
Version: serverless@1.26.1
Steps to reproduce: Create any/simple stack which uses this plugin, and try to do a single-function deploy.

  Error --------------------------------------------------
 
  Unsupported type: data is neither a path or a Buffer
 
     For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.
 
  Stack Trace --------------------------------------------
 
Error: Unsupported type: data is neither a path or a Buffer
    at Object.ZipLocal.sync.unzip (/Users/farley/myService/node_modules/zip-local/main.js:386:15)
    at injectRequirements (/Users/farley/myService/node_modules/serverless-python-requirements/lib/inject.js:45:27)
    at ServerlessPythonRequirements.injectAllRequirements (/Users/farley/myService/node_modules/serverless-python-requirements/lib/inject.js:118:5)
From previous event:
    at PluginManager.invoke (/Users/farley/.npm-packages/lib/node_modules/serverless/lib/classes/PluginManager.js:372:22)
    at PluginManager.run (/Users/farley/.npm-packages/lib/node_modules/serverless/lib/classes/PluginManager.js:403:17)
    at variables.populateService.then (/Users/farley/.npm-packages/lib/node_modules/serverless/lib/Serverless.js:102:33)
    at runCallback (timers.js:672:20)
    at tryOnImmediate (timers.js:645:5)
    at processImmediate [as _immediateCallback] (timers.js:617:5)
From previous event:
    at Serverless.run (/Users/farley/.npm-packages/lib/node_modules/serverless/lib/Serverless.js:89:74)
    at serverless.init.then (/Users/farley/.npm-packages/lib/node_modules/serverless/bin/serverless:42:50)

# serverless.yml
service: myService

provider:
  name: aws
  runtime: python2.7

plugins:
  - serverless-python-requirements

custom: 
  pythonRequirements:
    dockerizePip: true

functions:
  hello:
    handler: handler.hello

# requirements.txt
requests

master/bleeding edge might not be ready yet, I was just developing something on top of it and ran into this.

Cheers!

[DHager]

Encountered this issue today, also with SLS 1.26.1, plugin 4.0.0.

[DHager]

Did a little more digging, it seems the plugin is trying to access the serverless.yml setting for package artifact which in my case is not specified, meaning that it tries to use an undefined value to find a zip file.

I do not know whether it is supposed to find the "whole project" zip-file (e.g. /dir/.serverless/servicename.zip) or just the function_name.zip that is generated along with sls deploy -f function_name.

[dschep]

How did I miss this bug before I released 4.0.0 😢

Weird that the tests pass since they only have 1 function and no package artifact specified.

It should be finding the "whole project" zip-file as you say @DHager, unless of course that package.individually is set.

[dschep]

Hey @AndrewFarley & @DHager did I miss something? I think 43e1404 should fail tests, but it doesn't.

[DHager]

@dschep While both seem to trigger the same "after" handler from plugin-hooks, it looks like when running sls package the value this.serverless.service.package.artifact is correctly pointing to the "big zip file". In contrast, when running sls deploy -f funcname the artifact is undefined.

I suspect what's happening is that a non-null artifact value is a side-effect of the packaging step, which is skipped when doing partial deploys. Specifically this part of the core serverless app:

packageAll() {
  const zipFileName = `${this.serverless.service.service}.zip`;

  return this.resolveFilePathsAll().then(filePaths =>
    this.zipFiles(filePaths, zipFileName).then(filePath => {
      // only set the default artifact for backward-compatibility
      // when no explicit artifact is defined
      if (!this.serverless.service.package.artifact) {
        this.serverless.service.package.artifact = filePath;
        this.serverless.service.artifact = filePath;
      }
      return filePath;
    })
  );
},

[DHager]

In other words, I think it boils down to "The service.package.artifact configuration value isn't reliable."

Possible approaches:

• Plugin uses some other mechanism (?) to discover the target zip file path, one which also works for per-function deploys.
• Plugin copies some of the logic from the core platform, and guesses the correct zip file path when an explicit value is not available.
• Core platform changes to always backfill the value, so that it is accessible to plugins during other operations.
• Core platform finds some other way to expose the ZIP path to all plugins doing per-function deploys.

[AndrewFarley]

In other words, I think it boils down to "The service.package.artifact configuration value isn't reliable."

If that is really the case, we should submit a patch upstream instead of fixing our plugin. However, I just tested, and it seems this problem is only in the latest (4.0.0) version of this plugin, if I force-use a previous release this problem goes away, which means, it's something we can fix and/or something that broke in the latest release. I admit, it is really annoying to not be able to do single-function deploys assisting in more rapid development, so I hope someone can fix this soon. I'll get around to it eventually if no one else does.

[dschep]

I agree that an upstream patch is desirable @AndrewFarley. I asked over in the serverless-contrib slack if anyone had thoughts on it but got no responses 🤷‍♂️

[dschep]

Created an issue upstream ☝️

[AndrewFarley]

So, upstream patches aside, this works fine right now with pre-4.0 of this plugin. So, to me that says there is something we can do right now without having to wait for them to fix this upstream, no?