Merge branch 'master' into issue-1604

CHANGELOG.md

@@ -1,3 +1,31 @@
+# 1.1.0 (02.11.2016)
+
+* [Github Milestone](https://github.com/serverless/serverless/milestone/15)
+* [Comparison since last release](https://github.com/serverless/serverless/compare/v1.0.3...v1.1.0)
+
+## Future breaking changes
+We will include the LogGroup for your Lambda function in the CloudFormation template in the future. This will break deployments to existing applications because the log group was already created. You will get a warning about this if you deploy currently. We will force this behaviour in a future release, for now you can set it through the `cfLogs: true` parameter in your provider config. This change will also limit the logging rights to only this LogGroup, which should have no impact on your environment. You can read more in [our docs](https://serverless.com/framework/docs/providers/aws/guide/functions#log-group-resources).
+
+## Features
+* [Rollback Support](https://serverless.com/framework/docs/providers/aws/cli-reference/rollback/) (#2495)
+* [Log Groups in Cloudformation](https://serverless.com/framework/docs/providers/aws/guide/functions#log-group-resources) (#2520)
+* [Allow Services without functions](https://github.com/serverless/serverless/pull/2499) (#2499)
+* [Clean up S3 Deployment bucket only after successful deployment](https://github.com/serverless/serverless/pull/2564) (#2564)
+* [Allow Inclusion after Exclusion using ! Globs](https://serverless.com/framework/docs/providers/aws/guide/packaging/) (#2266)
+* [Version Pinning for Serverless Services to only deploy with specified versions](https://serverless.com/framework/docs/providers/aws/guide/version/) (#2505)
+* [Invoke local plugin](https://serverless.com/framework/docs/providers/aws/cli-reference/invoke/) (#2533)
+* [Plugin template](https://serverless.com/framework/docs/providers/aws/cli-reference/create/) (#2581)
+* [Simple Plugins are now installable in subfolder of the service](https://serverless.com/framework/docs/providers/aws/guide/plugins#service-local-plugin) (#2581)
+
+## Bugs
+* Fix variable syntax fallback if the file doesn't exist (#2565)
+* Fix overwriting undefined variables (#2541)
+* Fix CF deployment issue (#2576)
+* Correctly package symlinks (#2266)
+
+## Other
+* [Large documentation refactoring](https://serverless.com/framework/docs/) (#2527)
+
 # 1.0.3 (21.10.2016)
 
 Following is a selection of features, bug fixes and other changes we did since 1.0.2.

README.md

@@ -18,6 +18,8 @@ Serverless is an MIT open-source project, actively maintained by a full-time, ve
 
 <a href="https://serverless.com/framework/" target="_blank">Watch the video guide here.</a>
 
+<a href="https://goo.gl/forms/4AvkCrSf5oDOytDv1" target="_blank">Serverless Framework Feedback Survey</a>
+
 ## Contents
 
 * [Quick Start](#quick-start)
@@ -112,7 +114,9 @@ Use these plugins to overwrite or extend the Framework's functionality…
 
 * [serverless-offline](https://github.com/dherault/serverless-offline) - Emulate AWS Lambda and API Gateway locally to speed up your development cycles.
 * [serverless-webpack](https://github.com/elastic-coders/serverless-webpack) - Bundle your lambdas with Webpack
+* [serverless-plugin-browserify](https://github.com/doapp-ryanp/serverless-plugin-browserify) - Bundle your lambdas with Browserify
 * [serverless-alexa-plugin](https://github.com/rajington/serverless-alexa-plugin) - Support Alexa Lambda events
+* [serverless-optimizer](https://github.com/FidelLimited/serverless-plugin-optimize) - Bundle with Browserify, transpile with Babel to ES5 and minify with Uglify your Serverless functions.
 * [serverless-run-function](https://github.com/lithin/serverless-run-function-plugin) - Run functions locally
 * [serverless-plugin-write-env-vars](https://github.com/silvermine/serverless-plugin-write-env-vars)
 * [serverless-plugin-multiple-responses](https://github.com/silvermine/serverless-plugin-multiple-responses)
@@ -122,6 +126,7 @@ Use these plugins to overwrite or extend the Framework's functionality…
 * [serverless-dynamodb-local](https://github.com/99xt/serverless-dynamodb-local/tree/v1)
 * [serverless-wsgi](https://github.com/logandk/serverless-wsgi) - Deploy Python WSGI applications (Flask/Django etc.)
 * [serverless-command-line-event-args](https://github.com/horike37/serverless-command-line-event-args) - Event json passes to your Lambda function in commandline
+* [serverless-subscription-filter](https://github.com/blackevil245/serverless-subscription-filter) - Register and pipe the logs of one lambda to another to process.
 
 ## <a name="v1-projects"></a>Example Projects (V1.0)
 
@@ -172,6 +177,7 @@ These consultants use the Serverless Framework and can help you build your serve
 * [cloudonaut](https://cloudonaut.io/serverless-consulting/)
 * [PromptWorks](https://www.promptworks.com/serverless/)
 * [Craftship](https://craftship.io)
+* [EPX Labs](http://www.epxlabs.com/) - runs [Serverless NYC Meetup](https://www.meetup.com/Serverless-NYC/)
 
 ----
 
@@ -215,3 +221,4 @@ Serverless is composed of Plugins.  A group of default Plugins ship with the Fra
 * [Serverless Secrets](https://github.com/trek10inc/serverless-secrets) - Easily encrypt and decrypt secrets in your Serverless projects
 * [Serverless DynamoDB Local](https://github.com/99xt/serverless-dynamodb-local) - Simulate DynamoDB instance locally.
 * [Serverless Dependency Install](https://github.com/99xt/serverless-dependency-install) - Manage node, serverless dependencies easily within the project.
+* [Serverless Header Function](https://github.com/blackevil245/serverless-header-function) - Automatically run a javascript script on every Serverless action hooks.

RELEASE_CHECKLIST.md

@@ -5,7 +5,7 @@ This checklist should be worked through when releasing a new Serverless version.
 ## Pre-Release
 - [ ] Look through all open issues and PRs (if any) of that milestone and close them / move them to another
 milestone if still open
-- [ ] Look through all closed issues and PRs of that milestone to see what has changed. Run `git log --grep "Merge pull request" "LAST_TAG_HERE"..HEAD --pretty=oneline --abbrev-commit > gitlogoutput` to get a list of all merged PR's since a specific tag.
+- [ ] Look through all closed issues and PRs of that milestone to see what has changed. Run `./scripts/pr-since-last tag` or if you want to run against a specific tag `./scripts/pr-since-last tag v1.0.3` to get a list of all merged PR's since a specific tag.
 - [ ] Create Changelog for this new release
 - [ ] Close milestone on Github
 - [ ] Create a new release in GitHub for Release Notes.

docs/README.md

@@ -52,6 +52,7 @@ The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, e
         <li><a href="./providers/aws/cli-reference/invoke.md">Invoke</a></li>
         <li><a href="./providers/aws/cli-reference/logs.md">Logs</a></li>
         <li><a href="./providers/aws/cli-reference/info.md">Info</a></li>
+        <li><a href="./providers/aws/cli-reference/rollback.md">Rollback</a></li>
         <li><a href="./providers/aws/cli-reference/remove.md">Remove</a></li>
         <li><a href="./providers/aws/cli-reference/slstats.md">Serverless Stats</a></li>
       </ul>

docs/providers/aws/cli-reference/create.md

@@ -37,6 +37,7 @@ Most commonly used templates:
 - aws-java-maven
 - aws-java-gradle
 - aws-scala-sbt
+- plugin
 
 ## Examples
 
@@ -63,4 +64,12 @@ will be generated in the `my-new-service` directory. This directory will be crea
 will use the already present directory.
 
 Additionally Serverless will rename the service according to the path you provide. In this example the service will be
-renamed to `my-new-service`.
+renamed to `my-new-service`.
+
+### Creating a new plugin
+
+```
+serverless create --template plugin
+```
+
+This example will generate scaffolding for a hello world plugin that demonstrates how to create a new command and how to listen to the various events available.

docs/providers/aws/cli-reference/deploy.md

@@ -46,6 +46,14 @@ serverless deploy --stage production --region eu-central-1
 With this example we've defined that we want our service to be deployed to the `production` stage in the region
 `eu-central-1`.
 
+## List existing deploys
+
+```
+serverless deploy list
+```
+
+Running this command will list your recent deployments available in your S3 deployment bucket. It will use stage and region from the provider config and show the timestamp of each deployment so you can roll back if necessary.
+
 ## Provided lifecycle events
 - `deploy:cleanup`
 - `deploy:initialize`
@@ -54,4 +62,4 @@ With this example we've defined that we want our service to be deployed to the `
 - `deploy:compileFunctions`
 - `deploy:compileEvents`
 - `deploy:deploy`
-- `deploy:function:deploy`
+- `deploy:function:deploy`

docs/providers/aws/cli-reference/invoke.md

@@ -15,7 +15,7 @@ layout: Doc
 Invokes a previously deployed function. It allows to send event data to the function and read logs and display other important information of the function invoke.
 
 ```bash
-serverless invoke --function functionName
+serverless invoke [local] --function functionName
 ```
 
 ## Options
@@ -27,10 +27,26 @@ root directory of the service.
 - `--type` or `-t` The type of invocation. Either `RequestResponse`, `Event` or `DryRun`. Default is `RequestResponse`.
 - `--log` or `-l` If set to `true` and invocation type is `RequestResponse`, it will output logging data of the invocation.
 Default is `false`.
+- `--data` or `-d` String data to be passed as an event to your function.
 
 ## Provided lifecycle events
 - `invoke:invoke`
 
+
+# Invoke Local
+
+Invokes a function locally for testing and logs the output. You can only invoke Node.js runtime locally at the moment. Keep in mind that we mock the `context` with simple mock data.
+
+```bash
+serverless invoke local --function functionName
+```
+
+## Options
+- `--function` or `-f` The name of the function in your service that you want to invoke locally. **Required**.
+- `--path` or `-p` The path to a json file holding input data to be passed to the invoked function. This path is relative to the
+root directory of the service. The json file should have event and context properties to hold your mocked event and context data.
+- `--data` or `-d` String data to be passed as an event to your function. Keep in mind that if you pass both `--path` and `--data`, the data included in the `--path` file will overwrite the data you passed with the `--data` flag.
+
 ## Examples
 
 ### AWS
@@ -57,4 +73,31 @@ serverless invoke --function functionName --stage dev --region us-east-1 --path
 ```
 
 This example will pass the json data in the `lib/data.json` file (relative to the root of the service) while invoking
-the specified/deployed function.
+the specified/deployed function.
+
+#### Local function invocation
+
+```bash
+serverless invoke local --function functionName
+```
+
+This example will locally invoke your function.
+
+
+#### Local function invocation with event data
+
+You can input test data in `event.json` file inside your service directory:
+```json
+{
+  "foo": "bar"
+}
+
+```
+
+and then pass it with the command
+
+```bash
+serverless invoke local --function functionName --path event.json
+```
+
+This example will locally invoke your function.

docs/providers/aws/cli-reference/rollback.md

@@ -0,0 +1,77 @@
+<!--
+title: Serverless Rollback CLI Command
+menuText: Rollback
+menuOrder: 9
+description: Rollback the Serverless service to a specific deployment
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/aws/cli-reference/rollback)
+<!-- DOCS-SITE-LINK:END -->
+
+
+# Rollback
+
+Rollback the Serverless service to a specific deployment.
+
+```bash
+serverless rollback --timestamp timestamp
+```
+
+## Options
+- `--timestamp` or `-t` The stage in your service you want to display information about.
+- `--verbose` or `-v` Shows any Stack Output.
+
+## Provided lifecycle events
+- `rollback:initialize`
+- `rollback:rollback`
+
+## Examples
+
+### AWS
+
+At first you want to run `serverless deploy list` to show your existing deployments. This will provide you with a list of the deployments stored in your S3 bucket. You can use the timestamp of one of these deployments to set your infrastructure stack to this specific deployment.
+
+**Example:**
+
+```
+$ serverless deploy list
+Serverless: Listing deployments:
+Serverless: -------------
+Serverless: Timestamp: 1476790110568
+Serverless: Datetime: 2016-10-18T11:28:30.568Z
+Serverless: Files:
+Serverless: - compiled-cloudformation-template.json
+Serverless: - mail-service.zip
+Serverless: -------------
+Serverless: Timestamp: 1476889476243
+Serverless: Datetime: 2016-10-19T15:04:36.243Z
+Serverless: Files:
+Serverless: - compiled-cloudformation-template.json
+Serverless: - mail-service.zip
+Serverless: -------------
+Serverless: Timestamp: 1476893957131
+Serverless: Datetime: 2016-10-19T16:19:17.131Z
+Serverless: Files:
+Serverless: - compiled-cloudformation-template.json
+Serverless: - mail-service.zip
+Serverless: -------------
+Serverless: Timestamp: 1476895175540
+Serverless: Datetime: 2016-10-19T16:39:35.540Z
+Serverless: Files:
+Serverless: - compiled-cloudformation-template.json
+Serverless: - mail-service.zip
+Serverless: -------------
+Serverless: Timestamp: 1476993293402
+Serverless: Datetime: 2016-10-20T19:54:53.402Z
+Serverless: Files:
+Serverless: - compiled-cloudformation-template.json
+Serverless: - mail-service.zip
+
+$ serverless rollback -t 1476893957131
+Serverless: Updating Stack…
+Serverless: Checking Stack update progress…
+.....
+Serverless: Stack update finished…
+```

docs/providers/aws/events/apigateway.md

@@ -199,7 +199,8 @@ In case an exception is thrown in your lambda function AWS will send an error me
 You can specify a list of API keys to be used by your service Rest API by adding an `apiKeys` array property to the
 `provider` object in `serverless.yml`. You'll also need to explicitly specify which endpoints are `private` and require
 one of the api keys to be included in the request by adding a `private` boolean property to the `http` event object you
-want to set as private.
+want to set as private. API Keys are created globally, so if you want to deploy your service to different stages make sure
+your API key contains a stage variable as defined below.
 
 Here's an example configuration for setting API keys for your service Rest API:
 
@@ -209,6 +210,7 @@ provider:
   name: aws
   apiKeys:
     - myFirstKey
+    - ${opt:stage}-myFirstKey
     - ${env:MY_API_KEY} # you can hide it in a serverless variable
 functions:
   hello:

docs/providers/aws/guide/packaging.md

@@ -29,37 +29,43 @@ Exclude all node_modules but then re-include a specific modules (in this case no
 package:
   exclude:
     - node_modules/**
-    - "!node_modules/node-fetch/**"
+    - '!node_modules/node-fetch/**'
+```
+
+Exclude all files but `handler.js`
+
+``` yaml
+package:
+  exclude:
+    - "!src/function/handler.js"
 ```
 
 ```
 exclude:
   - tmp/**
-  - .git
+  - .git/**
 ```
 
 ## Artifact
-For complete control over the packaging process you can specify your own zip file for your service. Serverless won't zip your service if this is configured so `include` and `exclude` will be ignored.
+
+For complete control over the packaging process you can specify your own zip file for your service. Serverless won't zip your service if this is configured so `exclude` will be ignored.
 
 ## Example
 
 ```yaml
 service: my-service
 package:
-  include:
-    - lib
-    - functions
   exclude:
-    - tmp
-    - .git
+    - tmp/**
+    - .git/**
   artifact: path/to/my-artifact.zip
 ```
 
 ## Packaging functions separately
 
 If you want even more controls over your functions for deployment you can configure them to be packaged independently. This allows you more control for optimizing your deployment. To enable individual packaging set `individually` to true in the service wide packaging settings.
 
-Then for every function you can use the same `include/exclude/artifact` config options as you can service wide. The `include/exclude` options will be merged with the service wide options to create one `include/exclude` config per function during packaging.
+Then for every function you can use the same `exclude / artifact` config options as you can service wide. The `exclude` option will be merged with the service wide options to create one `exclude` config per function during packaging.
 
 ```yaml
 service: my-service
@@ -71,9 +77,9 @@ functions:
   hello:
     handler: handler.hello
     package:
-      include:
+      exclude:
         # We're including this file so it will be in the final package of this function only
-        - excluded-by-default.json
+        - '!excluded-by-default.json'
   world:
     handler: handler.hello
     package:

docs/providers/aws/guide/plugins.md

@@ -14,8 +14,6 @@ layout: Doc
 
 A Plugin is custom Javascript code that creates new or extends existing commands within the Serverless Framework.  The Serverless Framework is merely a group of Plugins that are provided in the core.  If you or your organization have a specific workflow, install a pre-written Plugin or write a plugin to customize the Framework to your needs.  External Plugins are written exactly the same way as the core Plugins.
 
-If you or your organization have a specific workflow, install a pre-written Plugin or write a plugin to customize the Framework to your needs.  External Plugins are written exactly the same way as the core Plugins.
-
 ## Installing Plugins
 
 External Plugins are added on a per service basis and are not applied globally.  Make sure you are in your Service's root directory, then install the corresponding Plugin with the help of NPM:
@@ -44,6 +42,12 @@ custom:
   customkey: customvalue
 ```
 
+## Service local plugin
+
+If you are working on a plugin or have a plugin that is just designed for one project you can add them to the `.serverless_plugins` directory at the root of your service, and in the `plugins` array in `serverless.yml`.
+
+The plugin will be loaded based on being named `custom-serverless-plugin.js` or `custom-serverless-plugin\index.js` in the root of `.serverless_plugins` folder.
+
 ### Load Order
 
 Keep in mind that the order you define your plugins matters. When Serverless loads all the core plugins and then the custom plugins in the order you've defined them.
@@ -311,4 +315,4 @@ module.exports = MyPlugin;
 
 ### Command Naming
 
-Command names need to be unique. If we load two commands and both want to specify the same command (e.g. we have an integrated command `deploy` and an external command also wants to use `deploy`) the Serverless CLI will print an error and exit. If you want to have your own `deploy` command you need to name it something different like `myCompanyDeploy` so they don't clash with existing plugins.
+Command names need to be unique. If we load two commands and both want to specify the same command (e.g. we have an integrated command `deploy` and an external command also wants to use `deploy`) the Serverless CLI will print an error and exit. If you want to have your own `deploy` command you need to name it something different like `myCompanyDeploy` so they don't clash with existing plugins.