Wow @eahefnawy great job! 🎉 👍

Also love the guideline on how to test it! 💥 ❤️ it.

I had some problems with the outputs of the info plugin. This might be broken as it tries to access invalid CloudFormation Outputs properties.

Edit: Looked through the source code and added some minor comments.

One update:

Did a recent change to an already deployed service.

This one was what I've deployed at first:

functions:
  hello:
    handler: handler.hello
    events:
      - s3: serverless-logical-id-test
      - sns: topic-name
  world:
    handler: handler.world
    events:
      - s3:
          bucket: serverless-logical-id-test
          event: s3:ObjectRemoved:*
      - sns: topic-name

after that I changed it to (basically the service file you've mentioned in the PR description):

functions:
  hello:
    handler: handler.hello
    events:
      - s3: serverless-logical-id-test
      - schedule: rate(10 minutes)
      - http:
          path: users
          method: get
      - http:
          path: users
          method: post
      - sns: topic-name
  world:
    handler: handler.world
    events:
      - http:
          path: users/{number}
          method: post
      - sns: topic-name
      - s3: serverless-logical-id-test

which failed with the following error messages:

An error occurred while provisioning your cloudformation:
     The following resource(s) failed to create: [HelloEventsRule1,
     WorldLambdaPermissionApiGateway, HelloLambdaPermissionApiGateway].
     The following resource(s) failed to update: [S3BucketServerlesslogicalidtest].

Here's a screenshot of a part from the CloudFormation stack output on AWS:

@pmuens that error is intended and is because you can't add ObjectCreated twice through S3 in Cloudformation. If you want two functions to react to the same S3 event you need to push the event into SNS and then read it from SNS (I had the same issue and looked it up :D )

@eahefnawy Can you check out the CORS stuff as well, the naming there isn't correct yet:

ApiGatewayMethodPreflight0 Should imho be ApiGatewayMethodUsersCreateOptions as its simply creating an OPTIONS endpoint for a specific path. There is also a bug at the moment if you have multiple endpoints for the same path (e.g. GET and DELETE requests for users/create) the OPTIONS request will be replaced and only one of the HTTP Methods will be allowed)

Here's a link to the issue with the bug: #1960

Damn! Good catch @flomotlik!
Works like a charm. Here's the functions definition of the service I've used to test it:

functions:
  hello:
    handler: handler.hello
    events:
      - s3: serverless-logical-id-test
      - schedule: rate(10 minutes)
      - http:
          path: users
          method: get
      - http:
          path: users
          method: post
      - sns: topic-name
  world:
    handler: handler.world
    events:
      - http:
          path: users/{number}
          method: post
      - sns: topic-name
      - s3:
          bucket: serverless-logical-id-test
          event: s3:ObjectRemoved:*

HelloEventsRule1 should have Schedule as the name imho so HelloEventsRuleSchedule1 so if we add other EventsRule implementations we can distinguish them from schedule

IamRoleLambda -> IamRoleLambdaExecution to make it clear that this is the Lambda Execution Role and follow their naming conventions. Same with IamPolicyLambda

When doing that could we also update the corresponding template file names (e.g. here: https://github.com/serverless/serverless/tree/master/lib/plugins/aws/deploy/compile/functions).

So e.g.

iam-policy-lambda-template.json --> iam-policy-lambda-execution-template.json
iam-role-lambda-template.json --> iam-role-lambda-execution-template.json

@pmuens Really good catch! I was worried I'd miss something like that :)

I just made all the updates mentioned above, and I'm now looking into the CORS bug. Will keep you posted.

Will the base names be documented as part of this PR? I can see them in #1931 but it would be helpful to have them in the docs so that they can be referenced in custom resources.

@rowanu yup definitely!

Used the following configuration and the deployment and update failed on it. Please test with it and make sure it works before going further.

service: serverless-logical-id

custom:
  s3-bucket-name: serverless-logical-id-${opt:stage, self:provider.stage}

provider:
  name: aws
  runtime: nodejs4.3
  apiKeys:
    - myFirstKey
functions:
  hello1:
    handler: handler.hello
    events:
      - s3: ${self:custom.s3-bucket-name}
      - schedule: rate(10 minutes)
      - http:
          path: users
          method: get
      - http:
          path: users
          method: post
          cors: true
      - sns: topic-name
  world1:
    handler: handler.hello
    events:
      - http:
          path: users/{number}
          method: post
          authorizer: hello1
      - sns: topic-name
      - s3: 
          bucket: ${self:custom.s3-bucket-name}
          event: s3:ObjectRemoved:*

There is also a problem with updating an existing service as the the Code is only looking for the new deployment bucket and ignoring the old one. Adding the following to lib/plugins/aws/index.js makes it possible to detect the correct bucket, but still fails in other places. Please take a look so its possible to deploy on top of an existing service/bucket as well.

     ).then((result) => {
       const found = _.find(result.StackResources,
-        { LogicalResourceId: 'S3BucketServerlessDeploymentBucket' });
+        { LogicalResourceId: 'S3BucketServerlessDeploymentBucket' }) ||
+      _.find(result.StackResources,
+          { LogicalResourceId: 'ServerlessDeploymentBucket' });
       return found.PhysicalResourceId;
     });
   }

how can create an event to already exist Bucket with CF ?