Code Monkey home page Code Monkey logo

grunt-aws-lambda's Introduction

grunt-aws-lambda

A grunt plugin to assist in developing functions for AWS Lambda.

Build Status

This plugin provides helpers for:

  • Running Lambda functions locally
  • Managing npm dependencies which are required by your function
  • Packaging required dependencies with your function in a Lambda compatible zip
  • Uploading package to Lambda

Getting Started

This plugin requires Grunt ~0.4.5

If you haven't used Grunt before, be sure to check out the Getting Started guide, as it explains how to create a Gruntfile as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:

npm install grunt-aws-lambda --save-dev

Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:

grunt.loadNpmTasks('grunt-aws-lambda');

Gotchas

Add dist to your .npmignore

This will save you from packaging previous packages in future ones.

For example your .npmignore might look something like this:

event.json
Gruntfile.js
dist
*.iml

Read More

Authenticating to AWS

This library supports providing credentials for AWS via an IAM Role, an AWS CLI profile, environment variables, a JSON file on disk, or passed in credentials. To learn more, please see the below section

grunt-aws-lambda tasks

Overview

This plugin contains 3 tasks:

  • lambda_invoke - Wrapper to run and test lambda functions locally and view output.
  • lambda_package - Packages function along with any npm dependencies in a zip format suitable for lambda.
  • lambda_deploy - Uploads the zip package to lambda.

lambda_invoke and lambda_package can be used independently, lambda_deploy will invoke lambda_package before uploading the produced zip file.

lambda_invoke

In your project's Gruntfile, add a section named lambda_invoke to the data object passed into grunt.initConfig().

grunt.initConfig({
    lambda_invoke: {
        default: {
            options: {
                // Task-specific options go here.
            }
        }
    },
});

Options

options.handler

Type: String Default value: handler

Name of the handler function to invoke.

options.file_name

Type: String Default value: index.js

Name of your script file which contains your handler function.

options.event

Type: String Default value: event.json

Name of the .json file containing your test event relative to your Gruntfile.

Usage Examples

Default Options

In this example, the default options are used therefore if we have the following in our Gruntfile.js:

grunt.initConfig({
    lambda_invoke: {
        default: {
            options: {
                // Task-specific options go here.
            }
        }
    },
});

And the following in index.js

exports.handler = function (event, context) {
    console.log('value1 = ' + event.key1);
    console.log('value2 = ' + event.key2);
    console.log('value3 = ' + event.key3);

    context.done(null, 'Hello World');  // SUCCESS with message
};

And the following in event.json

{
    "key1": "value1",
    "key2": "value2",
    "key3": "value3"
}

Then we run grunt lambda_invoke, we should get the following output:

Running "lambda_invoke" task

value1 = value1
value2 = value2
value3 = value3

Message
-------
Hello World

Done, without errors.

lambda_package

This task generates a lambda package including npm dependencies using the default npm install functionality.

In your project's Gruntfile, add a section named lambda_package to the data object passed into grunt.initConfig().

grunt.initConfig({
    lambda_package: {
        default: {
            options: {
                // Task-specific options go here.
            }
        }
    },
});

Options

options.include_files

Type: Array Default value: []

List of files to explicitly include in the package, even if they would be ignored by NPM

options.include_time

Type: Boolean Default value: true

Whether or not to timestamp the packages, if set to true the current date/time will be included in the zip name, if false then the package name will be constant and consist of just the package name and version.

options.include_version

Type: Boolean Default value: true

Whether or not to include the NPM package version in the artifact package name. Set to false if you'd prefer a static package file name regardless of the version.

options.package_folder

Type: String Default value: ./

The path to your npm package, must contain the package.json file.

options.dist_folder

Type: String Default value: dist

The folder where the complete zip files should be saved relative to the Gruntfile.

Usage Examples

Default Options

In this example, the default options are used therefore if we have the following in our Gruntfile.js:

grunt.initConfig({
    lambda_package: {
        default: {
            options: {
                // Task-specific options go here.
            }
        }
    },
});

And the following in package.json

{
    "name": "my-lambda-function",
    "description": "An Example Lamda Function",
    "version": "0.0.1",
    "private": "true",
    "dependencies": {
        "jquery": "2.1.1"
    },
    "devDependencies": {
        "grunt": "0.4.*",
        "grunt-pack": "0.1.*",
        "grunt-aws-lambda": "0.1.*"
    }
}

Then we run grunt lambda_package, we should see a new zip file in a new folder called dist called something like:

my-lambda-function_0-0-1_2014-10-30-18-29-4.zip

If you unzip that and look inside you should see something like:

index.js
package.json
node_modules/
node_modules/jquery
node_modules/jquery/... etc

Given that by default the dist folder is inside your function folder you can easily end up bundling previous packages inside subsequent packages therefore it is strongly advised that you add dist to your .npmignore.

For example your .npmignore might look something like this:

event.json
Gruntfile.js
dist
*.iml

lambda_deploy

In your project's Gruntfile, add a section named lambda_deploy to the data object passed into grunt.initConfig().

grunt.initConfig({
    lambda_deploy: {
        default: {
            arn: 'arn:aws:lambda:us-east-1:123456781234:function:my-function',
            options: {
                // Task-specific options go here.
            }
        }
    },
});

Options

arn

Type: String Default value: None - Required

The ARN of your target Lambda function.

function

Type: String Default value: None - Required (if you havn't specified an ARN)

This option is deprecated, use arn instead. The name of your target Lambda function, ie. the name of the function in the AWS console.

Proxy

On Linux based hosts you can set proxy server for deploy task by specifying standard environment variable - https_proxy. E.g: env https_proxy=http://localhost:8080 grunt deploy

package

Type: String Default value: Package name set by package task of same target - see below.

The name of the package to be uploaded.

When the lambda_package task runs it sets the package value for the lambda_deploy target with the same name.

Therefore if lambda_package and lambda_deploy have a target (eg. default) with the same name you will not need to provide this value - it will be passed automatically.

For example, your Gruntfile.js might contain the following:

grunt.initConfig({
    lambda_deploy: {
        default: {
            arn: 'arn:aws:lambda:us-east-1:123456781234:function:my-function'
        }
    },
    lambda_package: {
        default: {
        }
    }
});

You could then run grunt lambda_package lambda_deploy and it'll automatically create the package and deploy it without having to specify a package name.

options.profile

Type: String Default value: null

If you wish to use a specific AWS credentials profile you can specify it here, otherwise it will use the environment default. You can also specify it with the environment variable AWS_PROFILE

options.RoleArn

Type: String Default value: null

If you wish to assume a specific role from an EC2 instance you can specify it here, otherwise it will use the environment default.

options.accessKeyId

Type: String Default value: null

If you wish to use hardcoded AWS credentials you should specify the Access Key ID here

options.secretAccessKey

Type: String Default value: null

If you wish to use hardcoded AWS credentials you should specify the Secret Access Key here

options.credentialsJSON

Type: String Default value: null

If you wish to use hardcoded AWS credentials saved in a JSON file, put the path to the JSON here. The JSON must conform to the AWS format.

options.region

Type: String Default value: us-east-1

Specify the AWS region your functions will be uploaded to. Note that if an ARN is supplied this option is not required.

options.timeout

Type: Integer Default value: null Depending on your Lambda function, you might need to increase the timeout value. The default timeout assigned by AWS is currently 3 seconds. If you wish to increase this timeout set the value here.

options.memory

Type: Integer Default value: null

Sets the memory assigned to the function. If null then the current setting for the function will be used. Value is in MB and must be a multiple of 64.

options.handler

Type: String Default value: null

Sets the handler for your lambda function. If left null, the current setting will remain unchanged.

options.enableVersioning

Type: boolean Default value: false

When enabled each deployment creates a new version.

options.aliases

Type: String or Array Default value: null

If a string or an array of strings then creates these aliases. If versioning enabled then points to the created version, otherwise points to $LATEST.

It is recommended that enableVersioning is also enabled when using this feature.

Examples:

Creates one beta alias:

aliases: 'beta'

Creates two aliases, alias1 and alias2:

aliases: [
    'alias1',
    'alias2'
]
options.enablePackageVersionAlias

Type: boolean Default value: false

When enabled creates a second alias using the NPM package version. When the NPM package version is bumped a new alias will be created, allowing you to keep the old alias available for backward compatibility.

It is recommended that enableVersioning is also enabled when using this feature.

options.subnetIds

Type: Array Default value: null

A list of one or more subnet IDs in your VPC.

options.securityGroupIds

Type: Array Default value: null

A list of one or more security groups IDs in your VPC.

If your Lambda function accesses resources in a VPC you must provide at least one security group and one subnet ID. These must belong to the same VPC

Usage Examples

Default Options

In this example, the default options are used therefore if we have the following in our Gruntfile.js:

grunt.initConfig({
    lambda_deploy: {
        default: {
            arn: 'arn:aws:lambda:us-east-1:123456781234:function:my-function'
        }
    }
});

And now if you run grunt lambda_deploy your package should be created and uploaded to the specified function.

Increasing the Timeout Options to 10 seconds

In this example, the timeout value is increased to 10 seconds and set memory to 256mb.

grunt.initConfig({
    lambda_deploy: {
        default: {
            arn: 'arn:aws:lambda:us-east-1:123456781234:function:my-function',
            options: {
                timeout : 10,
                memory: 256
            }
        }
    }
});
Example with a beta and prod deployment configuration

Deploy to beta with deploy and to prod with deploy_prod:

grunt.initConfig({
    lambda_invoke: {
        default: {
        }
    },
    lambda_deploy: {
        default: {
            options: {
                aliases: 'beta',
                enableVersioning: true
            },
            arn: 'arn:aws:lambda:us-east-1:123456789123:function:myfunction'
        },
        prod: {
            options: {
                aliases: 'prod',
                enableVersioning: true
            },
            arn: 'arn:aws:lambda:us-east-1:123456789123:function:myfunction'
        }
    },
    lambda_package: {
        default: {
        },
        prod: {
        }
    }
});

grunt.registerTask('deploy', ['lambda_package', 'lambda_deploy:default']);
grunt.registerTask('deploy_prod', ['lambda_package', 'lambda_deploy:prod']);

Misc info

Streamlining deploy

You can combine the lambda_package and lambda_deploy into a single deploy task by adding the following to your Gruntfile.js:

grunt.registerTask('deploy', ['lambda_package', 'lambda_deploy']);

You can then run grunt deploy to perform both these functions in one step.

AWS credentials

The AWS SDK is configured to look for credentials in the following order:

  1. an IAM Role (if running on EC2)
  2. an AWS CLI profile (from ~/.aws/credentials)
  3. environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN)
  4. a JSON file on disk
  5. Hardcoded credentials passed into grunt-aws

The preferred method of authenticating during local development is by providing credentials in ~/.aws/credentials, it should look something like this:

[default]
aws_access_key_id = <YOUR_ACCESS_KEY_ID>
aws_secret_access_key = <YOUR_SECRET_ACCESS_KEY>

For more information read this documentation.

AWS permissions

To run the deploy command the AWS credentials require permissions to access lambda including lambda:GetFunction, lambda:UploadFunction, lambda:UpdateFunctionCode, lambda:UpdateFunctionConfiguration and iam:PassRole for the role which is assigned to the function.

It is recommended that the following policy be applied to the user:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1442787227063",
      "Action": [
        "lambda:GetFunction",
        "lambda:UploadFunction",
        "lambda:UpdateFunctionCode",
        "lambda:UpdateFunctionConfiguration",
        "lambda:GetAlias",
        "lambda:UpdateAlias",
        "lambda:CreateAlias",
        "lambda:PublishVersion"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:lambda:*"
    },
    {
      "Sid": "Stmt1442787265773",
      "Action": [
        "iam:PassRole"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:iam::<my_account_id>:role/<my_role_name>"
    }
  ]
}

Contributing

In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using Grunt.

Release History

0.1.0

Initial release

0.2.0

Adding some unit tests, refactoring deploy task into single task and converting tasks to multitasks

0.3.0

Adding more warnings for various failure cases

0.4.0

0.5.0

  • Fixed issue where dotfiles weren't packaged - see issue 17
  • Fixed issue where task could be done before zip writing is finished - pull request by qen
  • Monkey patched node-archiver to force permissions to be 777 for all files in package - see issue 6

0.6.0

  • Fixing a minor issue caused by some code that shouldn't have been commented out.

0.7.0

  • Removing some unneeded files from the NPM package.

0.8.0

0.9.0

0.10.0

0.11.0

0.12.0

0.13.0

grunt-aws-lambda's People

Contributors

alekstr avatar bobhigs avatar caseyburns avatar dcaravana avatar dhleong avatar jonnybgod avatar jonyo avatar jvwing avatar newtom14 avatar olih avatar qen avatar robbiet480 avatar skorch avatar tim-b avatar tim92 avatar timdp avatar ubergoober avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

grunt-aws-lambda's Issues

Support absolute paths for dist_folder

In lambda_package.js, dist_folder gets prefixed with './'.

When I passed in an absolute path, on Windows, the task would never terminate (presumably because of some internal translation going on with './C:/...'. On *nix, it'll most likely happily create the subdir, but I'm guessing you can just leave out the './' prefix to end up with support for both absolute and relative paths.

Not a huge issue, but it's not really intuitive right now.

"Cannot find module 'npm'"

I use [email protected]. Using grunt-aws-lambda gives me:

Loading "lambda_package.js" tasks...ERROR
>> Error: Cannot find module 'npm'
>>     at Function.Module._resolveFilename (module.js:336:15)
>>     at Function.Module._load (module.js:278:25)
>>     at Module.require (module.js:365:17)
>>     at require (module.js:384:17)
>>     at Object.module.exports (node_modules\grunt-aws-lambda\tasks\lambda_package.js:14:15)

Looks like require('npm') no longer works by default with npm 3.

npm i [email protected] fixes it, so you can probably just include npm in the dependencies. No idea how you would elegantly pass the version of the globally installed npm though. A postinstall hook would work, I guess.

config does not pull default region from the environment

In the Lambda environment the default region used by the AWS SDK is the region in which the Lambda function is running. In the grunt-aws-lambda environment when running the task locally the region is not set. I have the region specified in ~/.aws/config as us-west-2 but it is not picking it up from there.

Here is the error thrown by the AWS SDK when I try to make a call to CloudWatchLogs api:
{ [ConfigError: Missing region in config]
message: 'Missing region in config',
code: 'ConfigError',
time: Fri Jul 03 2015 21:37:54 GMT-0700 (PDT) }

Missing required key 'FunctionName' in params

Running "lambda_deploy:prod" (lambda_deploy) task

AWS API request failed with undefined - MissingRequiredParameter: Missing required key 'FunctionName' in params

I've set the function option but I can't seem to avoid this message deploying to Lambda. Have there been API updates?

Here's my full conf.

    // Lambda
    lambda_invoke: {
        default: {
        }
    },
    lambda_deploy: {
        default: {
            options: {
                // aliases: 'prod',
                // enableVersioning: true
            },
            function: '<%= aws.AWSLambdaFunctionName =>',
            arn: '<%= aws.AWSLambdaARN %>'
        }
        // prod: {
        //     options: {
        //         aliases: 'prod',
        //         enableVersioning: true
        //     },
        //     arn: '<%= aws.AWSLambdaARN %>'
        // }
    },
    lambda_package: {
        default: {
        },
        prod: {
        }
    }
  });

Package upload failed, check you have lambda:UpdateFunctionCode permissions

Opening this issue just as a marker for anyone else who runs in to it...

I just ran grunt deploy and ended up getting the error:

Package upload failed, check you have lambda:UpdateFunctionCode permissions.

The actual err returned in the lambda.updateFunctionCode callback was toString failed, which happens when a buffer exceeds kMaxLength.

This is probably because the dist folder is not in your .npmignore file. The zip file has exceeded the max size of a buffer and the AWS SDK is choking on it.

Either add dist to .npmignore or clean out your dist folder.

If your package really does exceed the maximum buffer size (which sounds like it's around 2GB right now), then you'll likely need to upload to an S3 bucket first, as AWS.lambda.updateFunctionCode doesn't seem to support streams.

Root directory included in zip - not recognized by Amazon

With the following configuration:

lambda_package: {
  default: {
    options: {
      include_files: ['src/*.js'],
    }
  }
}

...grunt-aws-lambda creates a ZIP file with src at the root, meaning Lambda can't find the files. It looks like someone had a similar issue with archiver - archiverjs/node-archiver#142.

Is there another way I should be specifying or storing my source files? Thanks!!

Aliases and Versions are not created during deploy

Hi,

Aliases and Versions are not created when executing the 'deploy' command. The Grunt task has the following configuration:

lambda_deploy: {
    default: {
        'arn':'MyFunction',
        options: {
                    aliases: 'beta',
                    enableVersioning: true,
                    timeout:300,
                    memory: 128,
                    RoleArn:'SOME_ROLE_ARNA'
        }
    }
}

Am I missing something?

Deployment with versioning is not creating new versions

Hello,

I'm having an issue trying to create a task that deploys my lambda function to a new version, I have a dev/prod setup like in the attached image

image

I get no console errors, but best I can tell the new version was not created and the alias is not updated. Any idea what I'm doing wrong?

make the aws region configurable

The region for aws sdk is not configurable. The file 'lambda_deploy.js' has a hard coded value of us-west-1 for the region. As a result it is not possible to deploy to any other aws region.

Crash: MPValueTransformers.h - [NSNull null] passed into *toType arg

I've just installed Mixpanel (latest cocoapod), and I set up an A/B Experiment to update the text on a button. On launch, the app crashes on the function:

__unused static id transformValue(id value, NSString *toType)

on line 66:
if ([value isKindOfClass:[NSClassFromString(toType) class]]) {

toType is pointing to [NSNull null] rather than an NSString instance.

My base app is Swift. I'm running XCode 7.2.1

Task lambda_package create empty zip

I try to run the task on my iMac the generated zip doesn't contain any sources.

I added this piece of code to see files that are added to the archive. And I see nothing.

zipArchive.on('entry', function(data)   {
  console.log(data);
 });

Next I change the install_location to a directory on the project root, all the files to be compressed are listed correctly. But the archive is corrupt.

var install_location = "./.tmp";

Finally I changed the script that copies the archive to wait for the copy before deleting, and everything works.

output.on('close', function () {
  mkdirp('./' + options.dist_folder, function (err) {
    fs.createReadStream(install_location + '/' + archive_name + '.zip').pipe(
      fs.createWriteStream('./' + options.dist_folder + '/' + archive_name + '.zip')
    ).on('close', function(){
      rimraf(install_location, function () {
        grunt.config.set('lambda_deploy.' + task.target + '.package',
            './' + options.dist_folder + '/' + archive_name + '.zip');
        grunt.log.writeln('Created package at ' + options.dist_folder + '/' + archive_name + '.zip');
        done(true);
      });
    });
  });
});

I'm a beginner with node js and grunt, there is there a problem in my configuration or worries with the task ?

context.succeed() and context.fail() when using lambda_invoke

When you use grunt lambda_invoke on even the hello world script, it gives the error:

$ grunt lambda_invoke:HelloWorld
Running "lambda_invoke:HelloWorld" (lambda_invoke) task

Loading function
value1 = First Value
value2 = Second Value
value3 = Third Value
Warning: undefined is not a function Use --force to continue.

Aborted due to warnings.

I found the issue is that context.succeed function is not defined in the invoke.

Is this project still active? If so I can submit a PR to fix this by fully mocking the context object as documented in the AWS Lambda docs. Thanks!

Simulate context.clientContext for local invocation/testing

Are there any options to inject an object into the context called clientContext? The native mobile SDKs pass this in, which has device information, etc, as well as the local AWS Cognito identifier. This is the sort of information that will become more and more common once mobile developers start calling into Lambdas natively.

http://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestSyntax
http://docs.aws.amazon.com/mobileanalytics/latest/ug/PutEvents.html

Task "lambda_package" not found.

After uninstalling and reinstalling dependencies and grunt-aws-lambda 0.8.0, packaging no longer works for me. Prior to this version it was working even with the default empty lambda_package setting in Gruntfile.js.

Grunt 0.4.5
Grunt-Cli 0.1.13
Grunt-aws-lambda 0.8.0

Issue with deployment

Hi,

I have problems with deployment. The grunt deploy task is keep getting 404 and shows:

Running "lambda_package:default" (lambda_package) task
[email protected] 
Created package at ./dist/css-processor_1-0-0_2016-2-21-22-58-51.zip

Running "lambda_deploy:default" (lambda_deploy) task
Warning: Unable to find lambda function arn:aws:lambda:us-west-2:XXX:function:XX-css-processor, verify the lambda function name and AWS region are correct. Use --force to continue.

Aborted due to warnings.

I'm able to invoke the same function with aws-cli:

aws lambda invoke --function-name XXX-css-processor test
{
    "StatusCode": 200
}

I'm running

$ aws --version
aws-cli/1.10.14 Python/2.7.10 Darwin/14.5.0 botocore/1.4.5

Package.json

"devDependencies": {
    "grunt": "^0.4.5",
    "grunt-aws-lambda": "^0.12.0"
  }

Gruntfile.js

var grunt = require('grunt');
grunt.loadNpmTasks('grunt-aws-lambda');

grunt.initConfig({
    lambda_invoke: {
        default: {
        }
    },
    lambda_deploy: {
        options: {
            enableVersioning: true
        },
        default: {
            arn: 'arn:aws:lambda:us-west-2:XXX:function:XXX-css-processor'
        }
    },
    lambda_package: {
        default: {
        }
    },
});

grunt.registerTask('deploy', ['lambda_package:default', 'lambda_deploy:default']);

Am I doing something wrong? I have used this library before and never head problems with this. Do you see there something wrong? I'm sure that the Lambda function is working and I'm able to test it.

Support handler in lambda-deploy

Because you support file-name in lambad-invoke, so I can use other js file name, not default index.js. But if I use customized js file name, it doesn't work after deploy, because js file name is changed. To support it you have to support "handler" in lambda-deploy.

Unable to deploy using hardcoded credentials

So I'm trying to deploy using the recommended policy and with hardcoded creds (key, secret and region) and it's failing.

It DOES work if I use my root account creds in ~/.aws/credentials which I have removed

I am hardcoding it for a reason.

Am I the only one getting this issue?

LAMBDA_TASK_ROOT

In lambda the environment variable LAMBDA_TASK_ROOT is exported to the root of the unpacked archive. But grunt-aws-lambda does not seem to export it.

[Feature request] Allow deploy only if changed.

I am working with versioning my lambda functions and I am realizing two things.

  1. I cannot verify that the code I have locally has been deployed (either "deployed to any alias" or "deployed to X alias")
  2. I have to deploy the same code again to confirm it is deployed. This means my version numbers are climbing really fast.

Obviously version numbers don't matter, but if lambda is charging me for storage (though the cost is miniscule, a fraction of a fraction of a cent) I think it would be awesome to check for changes before deploying with this tool.

Maybe keep track of the version and alias for a given deploy and then when redeploying to that alias, check that the code is the same as the previously pushed version as well as that the alias is assigned to that version.

Unable to deploy

Unable to deploy to lambda when I run grunt deploy, getting following error:

Running "lambda_upload" task
Fatal error: Cannot read property 'Configuration' of null

My gruntfile is as follows:

var grunt = require('grunt');
grunt.loadNpmTasks('grunt-aws-lambda');

grunt.initConfig({
lambda_invoke: {
    default: {
      options: {
        file_name: 'index.js'
      }
    }
},
lambda_deploy: {
    default: {
        options: {
            timeout : 10,
            memory: 256            
        },
        arn: 'arn:aws:lambda:us-east-1:XXXXXXXX:function:XXXX'
    }
},
lambda_package: {
    default: {
    }
}
});

grunt.registerTask('deploy', ['lambda_package', 'lambda_deploy']);

I am able to run grunt lambda_package and get no issues. Tried running grunt lambda_deploy on its own, but to no avail.

lambda_deploy.<something>.options.handler ignored

Hi!

I want a setup where I have multiple different javascript files in my project. The different files export one handler each. I deploy the same package to different lambda functions which calls the different handlers. Unfortunately it seems that...

lambda_deploy..options.handler

...is ignored.

Example:
I setup my Gruntfile.js like this:

        lambda_deploy: {
                    default: {
                        arn: '<here goes my default function arn>',
                        options: {
                            // Task-specific options go here.
                        }
                    },
                    helloWorld: {
                        arn: '<here goes my helloWorld function arn>',
                        options: {
                            handler: 'helloWorld.handler'
                        }
                    }
                }

It seems to work if I add this code to lambda_deploy.js:

        if (options.handler !== null) {
            configParams.Handler = options.handler;
        }

Objects passed to the context output methods aren't serialized

It's common to call context.succeed context.error and context.done with an object instead of a string.

The lambda invoke task fails to output them, instead just printing the following

Success!  Message:
------------------
[object Object]

I think the output objects should be serialized so you get some sane output.

Fatal error in v8

Anyone else seeing this error on grunt deploy? It happens intermittently. I am also seeing very long times at Running "lambda_package:default" (lambda_package) task and very large packages (> 1GB) despite my codebase being quite a bit smaller.

Running "lambda_deploy:default" (lambda_deploy) task
Uploading...


#
# Fatal error in ../deps/v8/src/handles.h, line 48
# CHECK(location_ != NULL) failed
#

==== C stack trace ===============================

 1: ??
 2: ??
 3: ??
 4: ??
 5: ??
 6: ??
 7: ??
 8: ??
Illegal instruction: 4

Need check for archive size before upload

When the zip archive ends up being > 50MB the upload fails with the following (misleading) error message:

Warning: Package upload failed, check you have lambda:UpdateFunctionCode permissions. Use --force to continue.

There should be a check for the archive size before trying to upload.

Hidden files are not packaged

I have a hidden environment file call ".env" which is used to bootstrap environment variables using package "node-env-file", however I notice that the file is not being packaged.

Finding bundledDependencies

(I'm new at all this, so it's likely that I am doing something fundamentally wrong.)

My source tree look like this:

/Gruntfile.js
/package.json 
/node_modules/..../blah
/function1/index.js
/function1/package.json
/function2/index.js
/function2/package.json
/common/dependency_package/index.js
/common/dependency_package/package.json

dependency_package has been added to the dependencies and bundledDependencies sections of function1/package.json and function2/package.json.

I've installed dependency_package in / so it is in /node_modules/

When I run the lambda_invoke task everything works fine.

When I package with lambda_package, the task executes with no warning or error, but dependency_package is not included in the zip file. To have it included in the zip file I need to go into /function1/ and /function2/ directories and run npm install there.

I was hoping that grunt-aws-lambda would find the package by inspecting up the directory tree like require does. Failing that I was hoping that the plugin would issue an error if it cannot find bundledDependencies when building the zip.

using ~/.aws/credentials or environmental variables

Hi all,

I want to use this as part of my Travis CI setup. In practice this means I'd like to provide AWS credentials using my ~/.aws/credentials file when deploying locally, but using environmental variables when deploying on Travis. Is there any way to do this currently?

Thanks

Error in lambda_package.js

Hi,
Thanks for this lovely plugin.

I have an error with running lambda_package I debugged and found that

grunt-aws-lambda/tasks/lambda_package.js Line 66:
npm.commands.install(install_location, options.package_folder , function () {

returns the follow error

Fatal error: Argument #2: Expected array but got string

When I change it to
npm.commands.install(install_location, [options.package_folder] , function () {

It works but I get the follow warnings
npm WARN ENOENT ENOENT, open '/private/var/folders/4r/9q6tv2_55257mkv4t9l7d4xw0000gn/T/1444468471486.175/package.json'
npm WARN EPACKAGEJSON /var/folders/4r/9q6tv2_55257mkv4t9l7d4xw0000gn/T/1444468471486.175 No description
npm WARN EPACKAGEJSON /var/folders/4r/9q6tv2_55257mkv4t9l7d4xw0000gn/T/1444468471486.175 No repository field.
npm WARN EPACKAGEJSON /var/folders/4r/9q6tv2_55257mkv4t9l7d4xw0000gn/T/1444468471486.175 No README data
npm WARN EPACKAGEJSON /var/folders/4r/9q6tv2_55257mkv4t9l7d4xw0000gn/T/1444468471486.175 No license field.

Any ideas how to fix it? My package.json file is

{
"name": "lambda-local",
"version": "1.0.0",
"description": "SMS Processor",
"main": "index.js",
"private": "true",
"dependencies": {
"aws-sdk": "^2.2.9",
"mysql": "^2.9.0",
"node-uuid": "^1.4.3",
"npm": "^3.1.2",
"request": "^2.64.0"
},
"devDependencies": {
"grunt": "^0.4.5",
"grunt-pack": "0.1.*",
"grunt-aws-lambda": "^0.8.0"
},
"license": "ISC",
"bundledDependencies": [
"aws-sdk",
"mysql",
"node-uuid",
"request"
]
}

Update aws-sdk dependency

AWS Lambda has moved its supported version of 'aws-sdk' to 2.2.3, while this project still shows a dependency on version ~2.1.30. It's quite annoying to have to see all the "unmet dependency" output when using npm.

Looking through the documentation, it doesn't look like there is anything between 2.1.35 and 2.2.3 that would cause the functionality to break. Can we please get a dependency version update?

Native extensions aren't being compiled

I'm attempting use grunt-aws-lambda for a project (https://github.com/kevinreedy/chef-asg-cleanup) that uses https://github.com/normanjoyner/chef-api. One of its dependencies is https://github.com/quartzjer/ursa, which has native extensions. When I run an npm install, the extensions are built! When I run grunt lambda_package, they are not. Steps to reproduce below:

$ git clone [email protected]:kevinreedy/chef-asg-cleanup.git
$ cd chef-asg-cleanup/
$ npm install
[output snipped]
$ grunt lambda_package
Running "lambda_package:default" (lambda_package) task
[email protected] ../../../tmp/1443742405683.5662/node_modules/chef-asg-cleanup
Created package at ./dist/chef-asg-cleanup_0-1-0_2015-9-1-23-33-25.zip

Done, without errors.
$ cd dist
$ unzip chef-asg-cleanup_0-1-0_2015-9-1-23-33-25.zip
[output snipped]
$ cd ..
root@8dd621056992:/usr/src/app# ls node_modules/chef-api/node_modules/ursa/build
Makefile  Release  binding.Makefile  config.gypi  ursaNative.target.mk
root@8dd621056992:/usr/src/app# ls dist/node_modules/chef-api/node_modules/ursa/build
ls: cannot access dist/node_modules/chef-api/node_modules/ursa/build: No such file or directory

I imagine there's an option that is needed to pass into npm.commands.install (https://github.com/Tim-B/grunt-aws-lambda/blob/master/tasks/lambda_package.js#L59-L66) to ensure that node-gyp gets called, but it's not obvious from looking at npm's code. Any thoughts to push me in the right direction? Thanks!

to know the memory ussage

It would be great to know how much memory has been used during the lambda_invokation process.

changing the callback function to something similar would be enought

var context = {
done: function (status, message) {
var success = status === null;
grunt.log.writeln("");
grunt.log.writeln("Message");
grunt.log.writeln("-------");
grunt.log.writeln(message);
grunt.log.writeln("");

            grunt.log.writeln("Memory usage");
            grunt.log.writeln("-------");
            grunt.log.writeln(util.inspect(process.memoryUsage()));
            done(success);
        }
    };

Only include a single JS file and node_modules in distribution?

Hey Tim, loving this repo... saving me a bunch of time & the documentation is great.

One suggestion. According to this AWS Lambda docs page, a Lambda deployment package only needs to contain a single JS file and the relevant node_modules. But it looks like this repo's lambda_package method is bundling other stuff from the project folder.

I'm able to bypass most of them with my .npmignore file, but package.json is still included. I don't think it's necessary here unless I'm missing something. Lambda seems to ignore these extraneous files, but it might be better to not include them in the first place.

This could be a good candidate for my first pull request. Maybe I can take a crack at it. Just LMK if I'm missing something...

node_modules missing from zip file

running lambda_package task creates a zip in /dist that is missing the /node_modules folder.

i tried setting the permissions on the node_modules, in case that was the problem. but no, it still persists.

it started happening after i deleted the node_modules folder and npm installed again. i also tried to copy the project into a new folder and the same is still happening.

did anyone encounter this issue before?

Incompatible with npm 3

With npm 3 on the way, I tried to get grunt-aws-lambda to support it. There are two main issues:

  1. The call to npm.commands.install in lambda_package.js should be updated to pass its second argument, the package to install, as an array rather than a string. Seems easy enough, and it worked in my tests.

  2. Unfortunately, because npm 3 flattens dependency structures rather than creating nested node_modules folders, you end up with something like

    temp
    |_  node_modules
        |_  myLambda
        |_  dependency1
        |_  dependency1.1
        |_  dependency1.2
        |_  dependency2
    

    IIRC (I didn't check), with npm 2, you would get the desired effect:

    temp
    |_  node_modules
        |_  myLambda
        |_  node_modules
            |_  dependency1
                |_  node_modules
                    |_  dependency1.1
                    |_  dependency1.2
            |_  dependency2
    

    I assume that what we're looking for with npm 3 is:

    temp
    |_  node_modules
        |_  myLambda
        |_  node_modules
            |_  dependency1
            |_  dependency1.1
            |_  dependency1.2
            |_  dependency2
    

    I'm not sure if that can be achieved by passing the appropriate arguments. Alternatively, I guess you could just move all the dependencies into that extra node_modules manually, but that seems messy.

    You can just depend on npm 2 for the time being, but I already wanted to document this issue for when npm 3 becomes mainstream.

lambda_deploy does not check if package exists

When you use grunt lambda_deploy it has no checks built in to make sure the given package file exists. The error is generic and makes it seem like the upload itself failed when there was really nothing to upload.

Like I mentioned in #8, if this project is still active I can submit a PR to fix this. Thanks!

Ability to verify response from `lambda_invoke`

Provides a function to invoke lambda with a event.json, but doesn't provide a facility to verify the response from the function. What is the purpose of this lambda_invoke without verification?

lambda_invoke swallows error stacktrace

When developing functions and invoking them using lambda_invoke, error (e.g. parse errors) stacktraces are getting swallowed up and I'm just getting the error string.

Is there a way to get the full trace? Thanks.

lambda_deploy fails if the function has not been created before

The lambda_deploy task fails because it executes a getFunction before uploading the packaged zip file.

Since the UploadFunction method is used to create and update functions, failing on a 404 response from the getFunction call is probably not the best practice.

I had to add npm to dev dependencies

Strange issue here. I have npm installed globally, but when I followed your setup instructions, it was choking on the lambda_package task with:

Loading "lambda_package.js" tasks...ERROR
>> Error: Cannot find module 'npm'

I added npm to the dev dependencies inside your project, and everything ran fine. Not sure why that is if you didn't encounter the same issue. Again, I have npm installed globally, so it seems like a strange error.

Exclusion feature

Hello,

Can you add the ability to exclude files in the lambda_package task? Or modify the include_files property to add only those files specified and not include the entire project folder? thanks.

Include config/ in deploy

Hey there! I just switched to using the config module which places private env variables in config/default.json. I noticed that the config file and directory is not being included with the .zip file that is uploaded to Lambda. Can someone recommend the right way to ensure that this directory is included? I am guessing it may have to do with .npmignore

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.