Git Product home page Git Product logo

serverless-finch's Introduction

serverless-finch

npm npm license

A Serverless Framework plugin for deployment of static website assets of your Serverless project to AWS S3.

Installation

npm install --save serverless-finch

Usage

First, update your serverless.yml by adding the following:

plugins:
  - serverless-finch

custom:
  client:
    bucketName: unique-s3-bucketname # (see Configuration Parameters below)
    # [other configuration parameters] (see Configuration Parameters below)

NOTE: For full example configurations, please refer to the examples folder.

Second, Create a website folder in the root directory of your Serverless project. This is where your distribution-ready website should live. By default the plugin expects the files to live in a folder called client/dist. But this is configurable with the distributionFolder option (see the Configuration Parameters below).

The plugin uploads the entire distributionFolder to S3 and configures the bucket to host the website and make it publicly available, also setting other options based the Configuration Parameters specified in serverless.yml.

To test the plugin initially you can copy/run the following commands in the root directory of your Serverless project to get a quick sample website for deployment:

mkdir -p client/dist
touch client/dist/index.html
touch client/dist/error.html
echo "Go Serverless" >> client/dist/index.html
echo "error page" >> client/dist/error.html

Third, run the plugin, and visit your new website!

serverless client deploy [--region $REGION] [--no-delete-contents] [--no-config-change] [--no-policy-change] [--no-cors-change]

The plugin should output the location of your newly deployed static site to the console.

Note: See Command-line Parameters for details on command above

WARNING: The plugin will overwrite any data you have in the bucket name you set above if it already exists.

If later on you want to take down the website you can use:

serverless client remove

Configuration Parameters

bucketName

required

custom:
  client:
    bucketName: unique-s3-bucketname

Use this parameter to specify a unique name for the S3 bucket that your files will be uploaded to.


tags

optional, default: none

custom:
  client:
    ...
    tags:
      tagKey: tagvalue
      tagKey2: tagValue2
    ...

Use this parameter to specify a list of tags as key:value pairs that will be assigned to your bucket.


distributionFolder

optional, default: client/dist

custom:
  client:
    ...
    distributionFolder: path/to/files
    ...

Use this parameter to specify the path that contains your website files to be uploaded. This path is relative to the path that your serverless.yaml configuration files resides in.


indexDocument

optional, default: index.html

custom:
  client:
    ...
    indexDocument: file-name.ext
    ...

The name of your index document inside your distributionFolder. This is the file that will be served to a client visiting the base URL for your website.


errorDocument

optional, default: error.html

custom:
  client:
    ...
    errorDocument: file-name.ext
    ...

The name of your error document inside your distributionFolder. This is the file that will be served to a client if their initial request returns an error (e.g. 404). For an SPA, you may want to set this to the same document specified in indexDocument so that all requests are redirected to your index document and routing can be handled on the client side by your SPA.


bucketPolicyFile

custom:
  client:
    ...
    bucketPolicyFile: path/to/policy.json
    ...

Use this parameter to specify the path to a single custom policy file. If not set, it defaults to a config for a basic static website. Currently, only JSON is supported. In your policy, make sure that your resource has the correct bucket name specified above: "Resource": "arn:aws:s3:::BUCKET_NAME/*",

Note: You can also use ${env:PWD} if you want to dynamically specify the policy within your repo. for example:

custom:
  client:
    ...
    bucketPolicyFile: "${env:PWD}/path/to/policy.json"
    ...

Additionally, you will want to specify different policies depending on your stage using ${self:provider.stage} to ensure your BUCKET_NAME corosponds to the stage.

custom:
  client:
    ...
    bucketPolicyFile: "/path/to/policy-${self:provider.stage}.json"
    ...

corsFile

custom:
  client:
    ...
    corsFile: path/to/cors.json
    ...

Path to a JSON file defining the bucket CORS configuration. If not set, it defaults to the configuration defined here. See above docs on bucketPolicyFile option for how to provide a dynamic file path.


objectHeaders

optional, no default

custom:
  client:
    ...
    objectHeaders:
      ALL_OBJECTS:
        - name: header-name
          value: header-value
        ...
      'someGlobPattern/*.html':
        - name: header-name
          value: header-value
        ...
      specific-directory/:
        - name: header-name
          value: header-value
        ...
      specific-file.ext:
        - name: header-name
          value: header-value
        ...
      ... # more file- or folder-specific rules
    ...

Use the objectHeaders option to set HTTP response headers be sent to clients requesting uploaded files from your website.

Headers may be specified globally for all files in the bucket by adding a name, value pair to the ALL_OBJECTS property of the objectHeaders option. They may also be specified for specific folders or files within your site by specifying properties with names like specific-directory/ (trailing slash required to indicate folder) or specific-file.ext, where the folder and/or file paths are relative to distributionFolder.

Headers with more specificity will take precedence over more general ones. For instance, if 'Cache-Control' was set to 'max-age=100' in ALL_OBJECTS and to 'max-age=500' in my/folder/, the files in my/folder/ would get a header of 'Cache-Control: max-age=500'.


redirectAllRequestsTo

optional, no default

custom:
  client:
    ...
    redirectAllRequestsTo:
      hostName: hostName
      protocol: protocol # "http" or "https"
    ...

Use the redirectAllRequestsTo option if you want to route all traffic coming to your website to a different address. hostName is the address that requests should be redirected to (e.g. 'www.other-website.com'). protocol is the protocol to use for the redirect and must be either 'http' or 'https'.

AWS Documentation


routingRules

optional, no default

custom:
  client:
    ...
    routingRules:
      - redirect:
          hostName: hostName
          httpRedirectCode: httpCode
          protocol: protocol # "http" or "https"
          replaceKeyPrefixWith: prefix
          replaceKeyWith: [object]
        condition:
          keyPrefixEquals: prefix
          httpErrorCodeReturnedEquals: httpCode
      - ...
    ...

The routingRules option can be used to define rules for when and how certain requests to your site should be redirected. Each rule in the redirectRules list consists of a (required) redirect definition and (optionally) a condition on which the redirect is applied.

The redirect property of each rule has five optional parameters:

  • hostName is the name of the host that the request should be redirected to (e.g. 'www.other-site.com'). Defaults to the host from the original request.
  • httpRedirectCode is the HTTP status code to use for the redirect (e.g. 301, 303, 308).
  • protocol is the protocol to use for the redirect and must be 'http' or 'https'. Defaults to the protocol from the original request.
  • replaceKeyPrefixWith specifies the string to replace the portion of the route specified in the keyPrefixEquals with in the redirect. For instance, if you want to redirect requests for pages starting with '/images' to pages starting with '/assets/images', you can specify keyPrefixEquals as '/images' and replaceKeyPrefixWith as '/assets/images'. Cannot be specified along with replaceKeyWith.
  • replaceKeyWith specifies a specific page to redirect requests to (e.g. 'landing.html'). Cannot be specified along with replaceKeyPrefixWith.

The condition property has two optional parameters:

  • keyPrefixEquals specifies that requests to pages starting with the specified value should be redirected. Often used with the replaceKeyPrefixWith and replaceKeyWith redirect properties.
  • httpErrorCodeReturnedEquals specifies that requests resulting in the given HTTP error code (e.g. 404, 500) should be redirected.

If condition is not specified, then all requests will be redirected in accordance with the specified redirect properties

AWS Documentation


uploadOrder

optional, no default

custom:
  client:
    ...
    uploadOrder:
      - .*
      - .*/assets/.*
      - service-worker\.js
      - index\.html
    ...

The uploadOrder option can be used to control the order that files are uploaded to the bucket. Each entry is evaluated as a case-insensitive regular expression. Unmatched files are uploaded first.

When combined with --no-delete-contents this can help with zero downtime (e.g. by uploading assets before the html files that depend on them).


keyPrefix

optional, no default

custom:
  client:
    ...
    keyPrefix: s3-folder/possible-sub-folder
    ...

Adding a keyPrefix option, so that it's possibly to upload files to a prefixed s3 path. You can use this to specify a key prefix path such as static so the deployment matches the naming conventions of popular frontend frameworks and tools.


sse

optional, no default

custom:
  client:
    ...
    sse: AES256
    ...

Enable server side encryption for the uploaded files. You can use AES256 or aws:kms.

AWS Documentation


manageResources

optional, default true (the plugin does manage your resources by default)

custom:
  client:
    ...
    manageResources: false
    ...

This allows you to opt out of having serverless-finch create or configure the s3 bucket. Instead, you can rely on an existing bucket or a CloudFormation definition.

Command-line Parameters

--region

optional, defaults to value specified in provider section of serverless.yml

serverless client deploy --region $REGION

Use this parameter to specify what AWS region your bucket will be deployed in.

This option will always determine the deployment region if specified. If region is not specified via the CLI, we use the region option specified under custom/client in serverless.yml. If that is not specified, we use the Serverless region specified under provider in serverless.yml.


--no-delete-contents

optional, default false (deletes contents by default)

serverless client deploy --no-delete-contents

Use this parameter if you do not want to delete the contents of your bucket before deployment. Files uploaded during deployment will still replace any corresponding files already in your bucket.


--no-config-change

optional, default false (overwrites bucket configuration by default)

serverless client deploy --no-config-change

Use this parameter if you do not want to overwrite the bucket configuration when deploying to your bucket.


--no-policy-change

optional, default false (overwrites bucket policy by default)

serverless client deploy --no-policy-change

Use this parameter if you do not want to overwrite the bucket policy when deploying to your bucket.


--no-cors-change

optional, default false (overwrites bucket CORS configuration by default)

serverless client deploy --no-cors-change

Use this parameter if you do not want to overwrite the bucket CORS configuration when deploying to your bucket.


--no-confirm

optional, default false (disables confirmation prompt)

serverless client deploy --no-confirm

Use this parameter if you do not want a confirmation prompt to interrupt automated builds.


Contributing

Please read our contribution guide.

Release Notes

See Releases for releases after v2.6.0.

v2.6.0

v2.5.0

  • Added the sse option to allow you to encrypt files with Server Side Encryption using AES256 or aws:kms - Pull 91 - Severi Haverila

v2.4.*

v2.0.*

  • Added ability to deploy files in a specific order to maximize uptime - Issue 63 - stefan-lz
  • Added Python tests of functionality to speed up development - fernando-mc
  • Major refactor of entire codebase to move towards modularity and testability
  • Added the ability to set HTTP headers for objects in bucket (Issue 24)
  • Added the ability to set redirect and routing options for the website (Initially implemented in Pull 23)
  • Added command-line options to disable (Initially implemented in Pull 28):
    • Bucket contents being deleted before deployment
    • Bucket configuration being overwritten on deployment
    • Bucket policy being overwritten on deployment
    • Bucket CORS configuration being overwritten on deployment
  • Added validation checks for all configuration options
  • Removed "stage" command-line option. It was not being used for anything

v1.4.*

  • Added the ability to set custom index and error documents. (Pull 20 - evanseeds)

v1.3.*

  • Added the ability to set a distributionFolder configuration value. This enables you to upload your website files from a custom directory (Pull 12 - pradel)
  • Updated the URL to the official static website endpoint URL (Pull 13 - amsross)
  • Added a new AWS region (Pull 14 - daguix)
  • Fixed an issue with resolving serverless variables (Pull 18 - shentonfreude)

v1.2.*

  • Added the remove option to tear down what you deploy. (Pull 10 thanks to redroot)
  • Fixed automated builds for the project (no functional differences)

Contributors

Forked from the serverless-client-s3

serverless-finch's People

Contributors

amsross avatar archanium avatar atlasgurus avatar benheymink avatar daguix avatar dependabot[bot] avatar dnalborczyk avatar evanseeds avatar fernando-mc avatar itsjesseyo avatar joelvh avatar josephnle avatar jrschumacher avatar jsphweid avatar lilja avatar linusmarco avatar mikejpeters avatar ol-ko avatar pradel avatar redhat-raptor avatar redroot avatar severi avatar shentonfreude avatar shereef avatar sprockow avatar stefan-lz avatar tahir-mm avatar triptec avatar warwithinme avatar wzedi 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  avatar  avatar  avatar  avatar  avatar

serverless-finch's Issues

Using keyPrefix results in an XML not well-formed or not validated error

This is a:

  • X Bug report

For bug reports:

Expected behavior

Using the 'keyPrefix: ...' param, i'm expecting the dirs and files in the bundles dir to appear in the bucket, underneath within the 'bundles' prefix (configured below) (eg. mybucket/bundles/abcd ... etc)
Eg;
custom:
client:
bucketName: mybucket
distributionFolder: public/bundles
keyPrefix: bundles

Actual behavior

$ sls client deploy --no-confirm

When deploying, it comes up with the following error;
Serverless: This deployment will:
Serverless: - Upload all files from 'public/bundles' to bucket 'mybucket'
Serverless: - Set (and overwrite) bucket 'mybucket' configuration
Serverless: - Set (and overwrite) bucket 'mybucket' bucket policy
Serverless: - Set (and overwrite) bucket 'mybucket' CORS policy
Serverless: Looking for bucket...
Serverless: Bucket found...
Serverless: Deleting all objects from bucket...

Serverless Error ---------------------------------------

ServerlessError: The XML you provided was not well-formed or did not validate against our published schema

Get Support --------------------------------------------
Docs: docs.serverless.com
Bugs: github.com/serverless/serverless/issues
Issues: forum.serverless.com

Your Environment Information ---------------------------
Operating System: linux
Node Version: 6.14.3
Serverless Version: 1.49.0
Enterprise Plugin Version: 1.3.5
Platform SDK Version: 2.1.0

Steps to reproduce

  • Operating system: linux
  • serverless-finch version: [email protected]
  • serverless.yml that produces bug:

custom:
client:
bucketName: mybucket
distributionFolder: public/bundles
keyPrefix: bundles
scripts:
hooks:
'deploy:createDeploymentArtifacts': sls client deploy --no-confirm

plugins:

  • ./vendor/bref/bref
  • serverless-plugin-scripts
  • serverless-finch

... (functions omitted) ...

  • Command that produces bug: sls client deploy --no-confirm
  • Other details:
    I've tried multiple ways and the only different seems to be the 'keyPrefix' to either make that error come up (by adding the keyPrefix), or go away (removing the keyPrefix)

Refactoring/structural improvements

(split out from #29)

This can be the home for general suggestions on structural improvements to the codebase (an we can break out to more specific issues when appropriate). Here are a few things that I think we can improve:

  1. Split out config-like variables into one or more json/yaml files (e.g. the region-to-URL map currently near the top of the code)
  2. Generally improve the level of modularity in the code. index.js can't house all the code forever 😃
  3. Refactor/restructure constructor and class methods to depend on less pre-configured state (to improve testability) -- suggested by @amsross

Any other suggestions? Any volunteers to take on some of this stuff?

Maintainers Needed!

There have been some great PRs with new functionality that I'd like to see included. The main two issues are that:

  1. I have limited time to review PRs
  2. I have more experience in Python than JavaScript which has limited my ability to efficiently review PRs

I'm looking for a few contributors who might be interested in taking a more active role reviewing, testing, and merging updates to the plugin.

@shentonfreude @redroot @amsross @kj187 @evanseeds @pradel @daguix and @linusmarco:

You've all either made contributions or have written PRs that I'm very likely going to merge after testing. Any chance some of you would have the experience/interest in a more active role?

Ideally, someone would be able to:

  1. Build new PRs locally and test them for the added functionality
  2. Build new PRs locally and test them to make sure they don't break existing functionality
  3. Review new PRs/Issues and give suggestions
  4. Have some JavaScript experience and give code suggestions or write tests

But even if you're just open to doing a few of these things (or know someone else who might be) I'm interested in hearing from you!

Upload static website files from custom directory

Any way to upload files from the ./www folder? I saw distributionFolder in the code but it seems to be joined to client parent folder. I'd like to be able to upload from the www folder in the root of the project

multiple sites for www redirect?

Is it possible to deploy multiple buckets within the one serverless.yml? For example, i'd like to be able to deploy domain.com with the client files and www.domain.com to redirect to domain.com or visa versa.

If this isn't supported currently I'd definately be interested in adding it as a feature if there is intrest.

End-to-end testing

(split out from #29)

Copied from #29, @fernando-mc's current testing process is below. Let's try to come up with a more standardized and automated set of e2e tests so that multiple people (or even just our CI) can share the burden. Anyone want to volunteer to take this on? I'm happy to chip in here as well.

  1. Review the code with no tests for syntax/potential errors without running it
  2. Wait for comments and updates from the contributor
  3. When I'm satisfied with changes I pull down the pr code from github with pr 10 for example to get pr 10. pr is aliased to this:
alias pr='f() { git fetch origin && git checkout pr/"$1"; }; f'
  1. I build an npm package from the modified code with npm pack. This outputs a gzipped(?) file.
  2. I move the gzipped file to a test directory and install it with npm install serverless-finch-long-name-withsomenumbers.gzip
  3. Then in that same directory I have a sample serverless.yml file and multiple subdirectories with different index.html and error.html files.
  4. I run a series of sls deploy sls remove sls deploy --region us-west-2 commands to try and emulate potential use cases.
  5. I test that each command deploys/removes correctly.

feat: automatic compression

This is a:

  • [✓] Feature request or change
  • [] Bug report

For feature requests or changes:

Current behavior (if any)

Specified files are uploaded as-is.

Proposed behavior

Option to compress before sending.

Justification

I turn off manage resources because I'm already creating the bucket in the serverless.yml. serverless-finch is very useful to specify a source directory and move only those files. Can an option be added to pre-compress the files, deal with what headers need to be dealt with?

I guess you'd want to support gzip and brotli

Print static website url upon completion

It would be nice to be able to have the amazon generated static website url generated upon completion.

e.g.

http://<bucket-name>.s3-website-<region>.amazonaws.com/

Feature suggestion: Allow user to set redirect options for the bucket

Now that the plugin allows for custom index and error documents ( #20 ), I think the next logical step on that path would be to allow users to specify the other two website configuration options: RedirectAllRequestsTo and RoutingRules (docs). Personally, I use routing/redirect rules on occasion, so it would be great to have the option to do this via the plugin (especially because these options get reset upon deploy currently).

I'd be happy to submit a PR for this if it's something that you think you'd want to include.

get bucket id for CF code?

This is a:

Question

With my previous manual S3 bucket + CF distribution I had a line under CF_resource/Properties/DistributionConfig/Origins:

- DomainName:
  'Fn::GetAtt': [ WebAppS3Bucket, DomainName ]

What's the best way to replace that with sls-finch plugin?

Thanks!

Deployment Strategies

I've added @linusmarco as a collaborator and fully expect to add a few more folks as collaborators soon.

Currently, I have set up the master branch as protected with these settings:
deployment

That means that any PRs can be merged to master after any collaborator approves them.

Deployment to npm is handled by Travis as described in the .travis.yml file. At present this is how new versions of the npm package are deployed:

  1. The commits are versioned with npm version patch/minor/major
  2. git tags are pushed alongside commits git push && git push --tags
  3. Travis sees this and builds the plugin and deploys it to npm

With @linusmarco as a collaborator now other PRs can be merged into the project without my approval. I believe I might still be a bottleneck for your prs @linusmarco so we need at least one more collaborator.

For new versions let's be especially careful to test all merged changes together to see if we've inadvertently broken anything.

For substantial changes to a plugin - Try to get at least two community sign-offs and some discussion on PRs before merging (and some tests soon!)

For non-controversial PRs - let's just get one approval and move forward. This can be for things like breaking out the constants for the plugin.

Deployed bucket cannot be removed from S3

This is a:

  • Bug report

For bug reports:

Expected behavior

The deployed bucket is expected to be removed successfully.

Actual behavior

The bucket cannot be deleted as the following error outputs.
ServerlessError: The bucket you tried to delete is not empty

Steps to reproduce

sls client deploy then sls client remove

  • Operating system: Ubuntu 18.04
  • serverless-finch version: 3.5.2
  • serverless.yml that produces bug:
service: my-bucket-test

provider:
  name: aws
  stage: ${opt:stage, 'dev'}
  runtime: nodejs6.10
  region: eu-west-2
  environment:
    LOGGING_LEVEL: DEBUG

  # Give the service full access to the configured notified bucket
  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "s3:*"
      Resource:
        - "arn:aws:s3:::my-bucket-test/*"
package:
  exclude:
    - ./**
  include:
    - ./dist/**

plugins:
  - serverless-finch

custom:
  client:
    bucketName: my-bucket-test
    distributionFolder: ./dist
  • Command that produces bug: sls client remove
  • Other details:
Serverless Error ---------------------------------------
 
  ServerlessError: The bucket you tried to delete is not empty
 
  Get Support --------------------------------------------
     Docs:          docs.serverless.com
     Bugs:          github.com/serverless/serverless/issues
     Issues:        forum.serverless.com
 
  Your Environment Information -----------------------------
     OS:                     linux
     Node Version:           8.10.0
     Serverless Version:     1.27.2

How to use

I'm a little bit confused on how to use this, after I added the module using npm install serverless-finch --save-dev, if I run serverless client ... there is no way this would work as there is no bin. How are we supposed to use this? the README is not clear enough imho

Add option for excluding files to deploy

This is a:

  • Feature request or change

Current behaviour

Finch deploys all files by default, including .DS_Store files

Proposed behavioir

Add option to exclude files to deploy by glob pattern

Justification

Lots of temporary files exist .gitignore, .DS_Store etc please consider an options for excluding these

Doesn't upload at all?

This is a:

  • [] Feature request or change
  • Bug report

Expected behavior

Works :)

Actual behavior

I'm stumped by its behaviour.
bucket is created ok
no files are uploaded into bucket except the CF json
on changing files, says nothing changed.
bucket is private

Steps to reproduce

Sounds like a strange issue. I reproduce it every time.
On macos, used 2.1.2 with sls 1.27.1 and 1.26.1, and finch 1.4.0 version with 1.27.1

Relevant section in serverless.yml:

  client:
    bucketName: ${self:custom.s3Bucket}
    distributionFolder: ./build
    indexDocument: index.html
    errorDocument: index.html

Also, I've tried index.html w and w/o paths, ./build or build which is in app package root as expected (it's a monorepo)
There are no other resources in that stage.
Hard to say what happened

  • Operating system:
  • serverless-finch version:
  • serverless.yml that produces bug:
  • Command that produces bug:
  • Other details:

Feature suggestion: Allow user to specify metadata for uploaded files

S3 bucket hosting allows you to set HTTP headers for responses to incoming requests via "Metadata" for each object in the bucket. It would be great to be able to specify these through the options in serverless.yml.

A specific use case for this would be for setting Cache-Control headers, which are particularly important for making sure that browsers don't cache files on your site that may change frequently.

I'm imagining this as an optional parameter in serverless.yml that could specify metadata for any specific file or folder as well as for the every object in the bucket. File-specific metadata would override folder-specific metadata, which would in turn override ALL_OBJECTS metadata.

custom:
  client:
    ...
    objectMetadata:
        - specific-file-that-shouldnt-be-cached:
            - mdata-name: Cache-Control
              mdata-value: no-cache
            - mdata-name: Content-Language
              mdata-value: es-ES
        - folder-with-other-caching-requirements:
            - mdata-name: Cache-Control
              mdata-value: max-age=10000
        - ALL_OBJECTS
            - mdata-name: Content-Language
              mdata-value: en-US

I'm happy to work on a PR for this

`client remove` functionality

I was wondering what you thought about adding remove as a CLI option, similar to the serverless remove command. In this case it would empty the bucket and delete it. I'm happy to work on the PR myself but wanted to make sure it wasn't a feature you were against?

Upload into folder

This is a:

  • [*] Feature request or change
  • [] Bug report

Proposed behavior

Upload into to folder of the bucket.

On Client Deploy - WARNING: Inappropriate call of provider.request()

THIS WAS SOLVED BY RELEASE OF SERVERLESS-FINCH V2

This is a:

  • Bug report

Expected behaviour

On running serverless client deploy the command executes without warnings.

Actual behavior

On running serverless client deploy the command executes successfully but with the following warning being logged about 40 times.

Serverless: WARNING: Inappropriate call of provider.request()

Steps to reproduce

  • Operating system:
    OS: macOS Sierra Version 10.12.6
    ZSH: zsh 5.4.1 (x86_64-apple-darwin16.7.0)

  • serverless-finch version:
    1.4.0

  • serverless.yml that produces bug:

service: shop

provider:
  name: aws
  runtime: nodejs6.10
  stage: ${opt:stage, self:custom.defaultStage}
  region: eu-west-1
  memorySize: 256
  timeout: 6
  versionFunctions: true

plugins:
  - serverless-plugin-optimize
  - serverless-plugin-scripts
  - serverless-finch

package:
  individually: true

functions:
  get-products:
    handler: lambda/get-products.handler
    name: shop-get-products-${self:provider.stage}
    description: 'Get product catalogue'
    environment:
      STRIPE_PUBLISHABLE_KEY: ${self:custom.stripe_publishable_key.${self:provider.stage}}
      STRIPE_SECRET_KEY: ${self:custom.stripe_secret_key.${self:provider.stage}}
    events:
      - http:
          path: products
          method: get
          cors: true
  create-charge:
    handler: lambda/create-charge.handler
    name: shop-create-charge-${self:provider.stage}
    description: 'Submit Stripe token to create charge for Shop'
    environment:
      STRIPE_PUBLISHABLE_KEY: ${self:custom.stripe_publishable_key.${self:provider.stage}}
      STRIPE_SECRET_KEY: ${self:custom.stripe_secret_key.${self:provider.stage}}
    events:
      - http:
          path: charge
          method: post
          cors: true

custom:
  defaultStage: dev
  client:
    bucketName: shop-site-${self:provider.stage}
    distributionFolder: build
    indexDocument: index.html
    errorDocument: index.html
  custom:
  optimize:
    minify: false
    global: false
    presets: ['babel-preset-node6']

  stripe_publishable_key:
    dev: ${file(env.yml):STRIPE_DEV_PUBLISHABLE_KEY}
    live: ${file(env.yml):STRIPE_LIVE_PUBLISHABLE_KEY}
  stripe_secret_key:
    dev: ${file(env.yml):STRIPE_DEV_SECRET_KEY}
    live: ${file(env.yml):STRIPE_LIVE_SECRET_KEY}
  • Command that produces bug:
    serverless client deploy
  • Other details:
    On running serverless client deploy the command executes successfully but prints the above warning repeatedly, mostly toward the end. Full terminal output logs below. I have also raised this in a more concise form on Stack Overflow two weeks ago but no joy. I've also searched through the Serverless docs but can't find any reference to this warning. Lastly, bug aside this is a great plugin, thanks for making!
Serverless: Load command run
Serverless: Load command config
Serverless: Load command config:credentials
Serverless: Load command create
Serverless: Load command install
Serverless: Load command package
Serverless: Load command deploy
Serverless: Load command deploy:function
Serverless: Load command deploy:list
Serverless: Load command deploy:list:functions
Serverless: Load command invoke
Serverless: Load command invoke:local
Serverless: Load command info
Serverless: Load command logs
Serverless: Load command login
Serverless: Load command logout
Serverless: Load command metrics
Serverless: Load command print
Serverless: Load command remove
Serverless: Load command rollback
Serverless: Load command rollback:function
Serverless: Load command slstats
Serverless: Load command plugin
Serverless: Load command plugin
Serverless: Load command plugin:install
Serverless: Load command plugin
Serverless: Load command plugin:uninstall
Serverless: Load command plugin
Serverless: Load command plugin:list
Serverless: Load command plugin
Serverless: Load command plugin:search
Serverless: Load command emit
Serverless: Load command config
Serverless: Load command config:credentials
Serverless: Load command rollback
Serverless: Load command rollback:function
Serverless: Load command client
Serverless: Load command client:deploy
Serverless: Load command client:remove
Serverless: Invoke client:deploy
Serverless: Deploying client to stage "dev" in region "eu-west-1"...
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: Bucket *********-site-dev exists
Serverless: Listing objects in bucket *********-site-dev...
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: Deleting all objects from bucket *********-site-dev...
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: Configuring website bucket *********-site-dev...
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: Configuring policy for bucket *********-site-dev...
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: Configuring CORS policy for bucket *********-site-dev...
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: Uploading file .DS_Store to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/.DS_Store
Serverless: Uploading file asset-manifest.json to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/asset-manifest.json
Serverless: Uploading file index.html to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/index.html
Serverless: Uploading file manifest.json to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/manifest.json
Serverless: Uploading file service-worker.js to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/service-worker.js
Serverless: Uploading file assets/.DS_Store to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/.DS_Store
Serverless: Uploading file assets/logo.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/logo.png
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: Uploading file assets/black-icons/.DS_Store to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/black-icons/.DS_Store
Serverless: Uploading file assets/black-icons/cupola.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/black-icons/cupola.png
Serverless: Uploading file assets/black-icons/kaleidoscope.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/black-icons/kaleidoscope.png
Serverless: Uploading file assets/black-icons/lloyds.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/black-icons/lloyds.png
Serverless: Uploading file assets/black-icons/pagoda.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/black-icons/pagoda.png
Serverless: Uploading file assets/black-icons/parabola.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/black-icons/parabola.png
Serverless: Uploading file assets/black-icons/stylite.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/black-icons/stylite.png
Serverless: Uploading file assets/drawings/kaleidoscope-0000mm.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/kaleidoscope-0000mm.png
Serverless: Uploading file assets/drawings/kaleidoscope-1160mm.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/kaleidoscope-1160mm.png
Serverless: Uploading file assets/drawings/kaleidoscope-1600mm.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/kaleidoscope-1600mm.png
Serverless: Uploading file assets/drawings/kaleidoscope-2000mm.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/kaleidoscope-2000mm.png
Serverless: Uploading file assets/drawings/lloyds-0000mm.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/lloyds-0000mm.png
Serverless: Uploading file assets/drawings/lloyds-1160mm.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/lloyds-1160mm.png
Serverless: Uploading file assets/drawings/lloyds-1600mm.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/lloyds-1600mm.png
Serverless: Uploading file assets/drawings/stylite-0000mm.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/stylite-0000mm.png
Serverless: Uploading file assets/drawings/stylite-1600mm.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/stylite-1600mm.png
Serverless: Uploading file assets/drawings/stylite-2000mm.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/stylite-2000mm.png
Serverless: Uploading file assets/products/parabola.jpg to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/products/parabola.jpg
Serverless: Uploading file assets/stylite/icon-black.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/stylite/icon-black.png
Serverless: Uploading file assets/stylite/icon-orange.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/stylite/icon-orange.png
Serverless: Uploading file assets/stylite/img-01.jpg to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/stylite/img-01.jpg
Serverless: Uploading file assets/stylite/img-2.jpg to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/stylite/img-2.jpg
Serverless: Uploading file assets/products/inside-sm.jpg to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/products/inside-sm.jpg
Serverless: Uploading file assets/products/inside.jpg to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/products/inside.jpg
Serverless: Uploading file assets/products/kaleidoscope.jpg to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/products/kaleidoscope.jpg
Serverless: Uploading file assets/products/led-rod-sm.jpg to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/products/led-rod-sm.jpg
Serverless: Uploading file assets/products/led-rod.jpg to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/products/led-rod.jpg
Serverless: Uploading file assets/products/lloydsproduct.jpg to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/products/lloydsproduct.jpg
Serverless: Uploading file assets/products/stylite-red.jpg to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/products/stylite-red.jpg
Serverless: Uploading file assets/products/stylite.jpg to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/products/stylite.jpg
Serverless: Uploading file static/css/main.79f99a9c.css to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/static/css/main.79f99a9c.css
Serverless: Uploading file static/css/main.79f99a9c.css.map to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/static/css/main.79f99a9c.css.map
Serverless: Uploading file static/js/main.8ee5a4e3.js to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/static/js/main.8ee5a4e3.js
Serverless: Uploading file static/js/main.8ee5a4e3.js.map to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/static/js/main.8ee5a4e3.js.map
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: Uploading file assets/drawings/singles/cupola-top.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/singles/cupola-top.png
Serverless: Uploading file assets/drawings/singles/kaleidoscope.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/singles/kaleidoscope.png
Serverless: Uploading file assets/drawings/singles/product-hero.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/singles/product-hero.png
Serverless: Uploading file assets/drawings/singles/lloyds.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/singles/lloyds.png
Serverless: Uploading file assets/drawings/singles/pagoda-top.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/singles/pagoda-top.png
Serverless: Uploading file assets/drawings/singles/parabola-top.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/singles/parabola-top.png
Serverless: Uploading file assets/drawings/singles/stylite.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/drawings/singles/stylite.png
Serverless: Uploading file assets/icons/other/left-arrow-highlight.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/icons/other/left-arrow-highlight.png
Serverless: Uploading file assets/icons/other/right-arrow-highlight.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/icons/other/right-arrow-highlight.png
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: Uploading file assets/icons/products/orange/cupola.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/icons/products/orange/cupola.png
Serverless: Uploading file assets/icons/products/orange/kaleidoscope.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/icons/products/orange/kaleidoscope.png
Serverless: Uploading file assets/icons/products/orange/lloyds.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/icons/products/orange/lloyds.png
Serverless: Uploading file assets/icons/products/orange/pagoda.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/icons/products/orange/pagoda.png
Serverless: Uploading file assets/icons/products/orange/parabola.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/icons/products/orange/parabola.png
Serverless: Uploading file assets/icons/products/orange/stylite.png to bucket *********-site-dev...
Serverless: If successful this should be deployed at:
Serverless: http://*********-site-dev.s3-website-eu-west-1.amazonaws.com/assets/icons/products/orange/stylite.png
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()
Serverless: WARNING: Inappropriate call of provider.request()

After upgrade to 2.0: ServerlessError: ReferenceError: index is not defined

This is a:

  • [] Feature request or change
  • Bug report

For bug reports:

Expected behavior

Running serverless client deploy my static site should be deployed to S3ˀ

Actual behavior

After upgrade to 2.0 I get the following error when running SLS_DEBUG=true serverless client deploy:

ServerlessError: ReferenceError: index is not defined
    at _validateConfig.then.then.catch.error (/Users/warrick/dev/orchestrated/people-mapper-ui/node_modules/serverless-finch/index.js:223:33)
From previous event:
    at Client._processDeployment (/Users/warrick/dev/orchestrated/people-mapper-ui/node_modules/serverless-finch/index.js:222:13)
    at Object.client:deploy:deploy [as hook] (/Users/warrick/dev/orchestrated/people-mapper-ui/node_modules/serverless-finch/index.js:45:14)
    at BbPromise.reduce (/Users/warrick/dev/orchestrated/people-mapper-ui/node_modules/serverless/lib/classes/PluginManager.js:372:55)
From previous event:
    at PluginManager.invoke (/Users/warrick/dev/orchestrated/people-mapper-ui/node_modules/serverless/lib/classes/PluginManager.js:372:22)
    at PluginManager.run (/Users/warrick/dev/orchestrated/people-mapper-ui/node_modules/serverless/lib/classes/PluginManager.js:403:17)
    at variables.populateService.then (/Users/warrick/dev/orchestrated/people-mapper-ui/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/warrick/dev/orchestrated/people-mapper-ui/node_modules/serverless/lib/Serverless.js:89:74)
    at serverless.init.then (/Users/warrick/dev/orchestrated/people-mapper-ui/node_modules/serverless/bin/serverless:42:50)

Steps to reproduce

  1. Upgrade to 2.0
  2. include WebsiteConfiguration with IndexDocument or ErrorDocument or both
  3. run serverless client deploy
  • Operating system:
    Mac OSX

  • serverless-finch version:
    2.0

  • serverless.yml that produces bug:
    Any serverless yml with WebsiteConfiguration IndexDocument and ErrorDocument will produce this error.

  • Command that produces bug:
    serverless client deploy

  • Other details:
    This error is reported immediately after an upgrade to serverless-finch 2.0.
    See lines 127 and 128 in index.js:
    indexDoc = this.options.indexDocument || index.html;
    errorDoc = this.options.errorDocument || error.html;

I think the default values should be explicit strings to fix this issue.

Customisation of S3 bucket policy on deploy

This is a:

Feature request or change


For feature requests or changes:

Current behavior (if any)

The serverless-finch defaults public access as S3 bucket policy

Proposed behavior

Customisation of S3 bucket policy

Proposed implementation deatils (optional)

Justification

With S3 bucket policy customisation, it would be more flexible.

Not Recognizing Pseudo Parameter

This is a:

  • Feature request or change
  • [] Bug report

For bug reports:

Expected behavior




Using serverless-pseudo-parameters pluging

custom:
  client:
    bucketName: ${self:provider.stage}-admin-dashboard-#{AWS::AccountId}

should create a bucket with name: dev-admin-dashboard-0123456

Actual behavior



Tries to create buck with name:

dev-admin-dashboard-#{AWS::AccountId}

and fails.

Steps to reproduce

  • Operating system:
  • serverless-finch version:
  • serverless.yml that produces bug:
  • Command that produces bug:
  • Other details:

For feature requests or changes:

Current behavior (if any)

Proposed behavior

Proposed implementation deatils (optional)

Justification

Build frontend with serverless.yml environment variables before deploying

Hi,

I have used serverless-finch for a few projects, and it works really well. The one thing I wish that I was able to do was to be able to build the frontend through Serverless before deploying to S3. My frontend makes requests to a backend, which is another Serverless project. I'd prefer not to hardcode this endpoint in my frontend. I'd rather make a cross-stack reference to the ServiceEndpoint and store it in an environment variable.

So I made a plugin called serverless-build-client, which adds a command to build the frontend with the environment variables. Then I can use serverless-finch to upload it to S3.

However, do you think that this command is something that should be included with serverless-finch out of the box rather than using another plugin? If so, I could look into adding this functionality rather than using another plugin, since I think it is a rather useful feature

Create CloudFront distribution OR get the bucket ARN

It would be nice to be able to choose how to serve the content, either via S3 with Static Web Hosting (as it is now), or via Cloudfront distribution.

If this is too much, it would be a good start to be able to retrieve the bucket ARN, so one could do the CloudFront provisioning via extra CloudFormation code.

Is there a way to achieve this?

Thanks!

Add linting

@amsross suggested that we add linting for standardization and to avoid having to catch/point that stuff out in PR review. I'm a big fan of prettier because it will both lint the code and can be set up to auto-format everything via editor plugins.

Here's my proposed setup:

package.json

...
"scripts": {
    "format": "prettier --write '**/*.js'",
    "pretest": "prettier --list-different '**/*.js'",
    "test": "mocha"
  },
...

This will lint and throw errors when npm test runs (locally or via CI). I also added a format script as a convenience so that contributors can clean up their code via the command prompt if they don't have prettier set up in their editor.

In terms of style choices, I think prettier's defaults take care of most of it, but here are my suggested settings (totally open to disagreement--just want to throw something out there):

.pretterrc

{
    "printWidth": 100, // overrides default of 80
    "singleQuote": true // prefers single quotes unless string contains single quotes
}

@amsross, @fernando-mc, any thoughts? I have a PR ready to put in with this if you're all okay with these settings.

Writing unit and integration tests

(split out from #29)

Let's try to get complete coverage of the code we have to help make sure that everything works as expected now and going forward as new functionality is added.

@fernando-mc, I can lead this charge.

If anyone has ideas for specific tests that we should include, please chime in here.

Reworking documentation

The current API reference consists of an inline sample yaml file, which works well for the limited set of options available on the current release, but most of the recent PRs add more options, some of which require more complex explanations.

To deal with this, I think we should move towards something more like this for documenting the options:

bucketName (required)

custom:
  client:
    bucketName: [unique-s3-bucketname]

Use this parameter to specify a unique name for the S3 bucket that your files will be uploaded to.

distributionFolder (optional, defaults to client/dist)

custom:
  client:
    ...
    distributionFolder: [path/to/files]

Use this parameter to specify the path that contains your website files to be uploaded. This path is relative to the path that your serverless.yaml configuration files resides in.

etc.

Thoughts?

Testing strategy

With the plugin growing pretty rapidly, @fernando-mc and I agree that it's going to be important to come up with a solid, standardized testing strategy.

I think that to start out we can do two things:

  1. Try to get close to 100% unit test coverage for the current functionality (and aim for similar on any new code)
  2. Standardize (and possibly automate parts of) the manual testing that @fernando-mc and other contributors do to make sure that the plugin properly deploys all objects and sets options as expected.

In the longer run, I think we should write proper end-to-end and integration tests to replace (2), but my opinion is that we can wait for now.

@fernando-mc, can you describe the process you currently use to test PRs--I think we can use that as a starting point for coming up with a standard battery of tests for (2).

I'm happy to spearhead the unit testing effort for (1), and work on (2) as well. Anyone else want to help out? @amsross @evanseeds

We're hoping that formalizing this stuff will speed up the process of accepting new contributions and reduce the chance that anything breaks along the way.

Selective deploy

Allow a command line option to specify which files to deploy, or even better take it as standard input so it can be piped with git diff.

Option to make AWS bucket content public rather than make a whole bucket public by bucket policy

This is a:

  • Feature request or change

Current behaviour

Finch allows creation of public buckets by bucket policy change but this is actively frowned upon due to known issues in users adding private files to public buckets, individual objects that are public should be made public.

Proposed behaviour

Add a flag that allows objects to be made public, this can be used in conjunction with the existing command line switches ---no-policy-change --no-config-change

Justification

AWS currently warns users about buckets which are public via bucket policy, making objects public by ACL is much more granular and highly preferred.

Doesn't upload to s3, no console output

This is a:

  • Bug report

For bug reports:

Expected behavior

serverless finch tries to upload files from build folder to s3 bucket and serverless outputs something to the console.

Actual behavior

nothing gets uploaded, there is no output to console.

Steps to reproduce

  • Operating system: Ubuntu 18.04
  • serverless-finch version: 1.3.1
  • serverless.yml that produces bug:
service: serverless-graphql-client

frameworkVersion: ">=1.21.0 <2.0.0"

provider:
  name: aws
  runtime: nodejs6.10
  stage: dev
  region: us-east-2

  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "s3:*"
      Resource:
        - "arn:aws:s3:::my-bucket-name/*"

plugins:
  - serverless-finch

custom:
  client:
    bucketName: my-bucket-name
    distributionFolder: build
  • Command that produces bug:
    sls client deploy
  • Other details:
    I tried to create the bucket myself before running the command, but the result is still the same. I'm running node v9.11.2

For feature requests or changes:

Current behavior (if any)

Proposed behavior

Proposed implementation deatils (optional)

Justification

Add support for S3 VPC-only endpoints

This is a:

  • [] Feature request or change

For feature requests or changes:

Current behavior (if any):

Current spec allows us to send in a BucketPolicy to restrict access to either IPs or VPCs. What we would like is for us to explicitly only listen / setup the bucket on the PRIVATE interface and attach that in a private VPC to limit public traffic. PR#59 only handles accomodating a bucket policy, not bucket setup (private v. public interface).

Proposed behavior

Take an ARN or explicit VPC-ID when setting up a bucket. If the VPC-ID exists, disable the public interface on the public bucket.

Proposed implementation details (optional)

See above.

Justification

We are writing a serverless app that should only be accessible on a private network. Our CIDR blocks change frequently, and we would like to have the S3-hosted application run only within a private, secure environment. Allowing traffic on a public interface increases exposure to risk.

cc: @ryanmalesic

Use custom cors configuration

This is a:

  • Feature request or change
  • Bug report

Current behavior (if any)

Serverless-finch will override s3 bucket CORS configuration or it does not touch the configuration at all.

Proposed behavior

User can provide custom CORS configuration for the bucket the same way as bucketPolicyFile works.

Proposed implementation details (optional)

Add new configuration setting bucketCorsConfiguration which would be the path to cors configuration .json file.

I have a proposal about how this could work if this is something that could be considered to be added in the future.

Justification

The project I'm currently working needs special cors configuration for the SPA to work correctly. We use serverless-finch but we have had to disable the cors configuration override since it would break our deployment every time. It would be great to manage the CORS settings with finch as well.

Region found in serverless.yml is not getting variable expanded

I'm deploying to different stages (shentonfreude, dev, test, prod) and each may have a different region defined in serverless.yml stage variables file custom_stage_variables.yml:

custom:
  stage: ${opt:stage, self:provider.stage}
  stage_variables: ${file(custom_stage_variables.yml)}
  client:
    bucketName: vmessage-frontend-${self:custom.stage}
    distributionFolder: vmessage/client
  region: ${self:custom.stage_variables.${self:custom.stage}.region}

Then the provider defines region, so that Finch can find it:

provider:
  name: aws
  runtime: python3.6
  region: ${self:custom.region}
  # ...

But when I try to deploy the client, it looks like Finch is not expanding the region variable:

$ sls client deploy --stage shentonfreude
Serverless: Deploying client to stage "shentonfreude" in region "${self:custom.region}"...
Serverless: Creating bucket vmessage-frontend-shentonfreude...
 
  Serverless Error ---------------------------------------
 
  A conflicting conditional operation is currently in progress against this resource. Please try again.

S3 is lying here, there's no resource conflict -- I think it just doesn't know what to do with "${self:custom.region}", since it's not expanding to "us-east-1" or "ap-southeast-2".

Am I using it wrong? or does Finch need to run the template interpolation over these variables, perhaps around here?
https://github.com/fernando-mc/serverless-finch/blob/master/index.js#L33

Deployment via windows breaks folder paths on S3

This is a:

  • Bug report

Expected behavior

When using Windows to deploy a dist folder that contains sub-directories, the file paths should translate to folders in S3.

ie. a file in dist\js\app.js within Windows should result in app.js being placed within a 'js' folder in the S3 bucket so that the relative path to that file becomes /js/app.js.

Actual behavior

Using the example above, a file in dist\js\app.js is written as js\app.js within the S3 bucket and the links to that file appears as /js%5Capp.js (instead of /js/app.js) and are therefore unreachable via the expected url, resulting in 404 errors.

Steps to reproduce

Deploy a distribution directory that contains sub-directories from a Windows machine.

  • Operating system: Windows 10
  • serverless-finch version: 2.1.0

Proposed fix

Replacing the Windows file separator '' with the Posix separator '/' on line 86 in /lib/upload.js does the trick for me.

fileKey: filePath.replace(clientRoot, '').replace(/\\/g, '/'),

Is it possible to deploy/copy files in a certain order

Hiya, I would like to be able to deploy files in a certain order, specifically the index.html file after all the other assets have been copied over. This will decrease downtime, as all the assets will be resolvable as soon as index.html is served.

I've worked around this by deploying using these 2 commands:

DIST_FOLDER=build_assets serverless client deploy --no-confirm --no-delete-contents
DIST_FOLDER=build_index serverless client deploy --no-confirm --no-delete-contents

with this config:

custom:
  client:
    bucketName: ${self:provider.domain}
    distributionFolder: ${env:DIST_FOLDER}

Am I missing an easier solution, or could this be better supported in finch?

Using outdated serverless request API

This is a:

  • Feature request or change
  • Bug report

Expected behavior

Our this.aws.request calls should use the most recent Serverless API:

  /**
   * Execute an AWS request by calling the AWS SDK
   * @param {string} service - Service name
   * @param {string} method - Method name
   * @param {Object} params - Parameters
   * @param {Object} [options] - Options to modify the request behavior
   * @prop [options.useCache] - Utilize cache to retrieve results
   */
  request(service, method, params, options) {
    ...

Actual behavior

We use the old API:

request(service, method, params, stage, region) 

Steps to reproduce

This is a problem for every deployment. It doesn't affect functionality because the old API still appears to be supported. However, you can see the warnings thrown by serverless if you run a test deployment with the environment variable SLS_DEBUG set to true:

export SLS_DEBUG=true
serverless client deploy -v
...
Serverless: Deploying client to stage "dev" in region "eu-west-1"...
Serverless: WARNING: Inappropriate call of provider.request()
...
  • Operating system: Ubuntu 16.04 LTS
  • serverless-finch version: 1.4.0

Setting up a domain name for site

Awesome project.

Is there way to set up a domain name for the deployed site?
Can i make it play nice with serverless-domain-manager plugin?

Feature request: Support serverless offline

This is a feature request.

Current behavior:

Running serverless offline (using the plugin serverless-offline) does not host the static files.

Proposed behavior:

Running serverless offline will host it in such manner that requesting localhost:3000 will return the index.html file.

deploy to `staging` and `production`

This is a:

  • Feature request or change

For feature requests or changes:

Current behavior (if any)

Removed "stage" command-line option. It was not being used for anything

Proposed behavior

Bring it back

Justification

Hey guys, thank you so much for your hard work. Since you removed the stage option, how do we deploy to staging and production?

Control is not return back when hooking with other serverless plugin

This is a:

  • Bug report

Expected behaviour

When using serverless-finch plugin with other serverless plugin (in our scenario custom build plugin) using hooks, serverless-finch not returning control back, due this we can not complete our other hooks which we want to execute after serverless-finch.

Actual behavior

serverless-finch plugin should return control back if we are using this with other serverless plugin.

Proposed implementation deatils (optional)

Just introduce return statement in following index.js file section.
this.hooks = { 'client:client': () => { serverless.cli.log(this.commands.client.usage); }, 'client:deploy:deploy': () => { return this._processDeployment(); }, 'client:remove:remove': () => { return this._removeDeployedResources(); } };

It will be much appreciated if @fernando-mc can fixed and published. Thanks

Specify key prefix

This is a:

  • Feature request or change
  • [] Bug report

For feature requests or changes:

Current behavior (if any)

Files can only be uploaded at the root level of the S3 bucket.

Proposed behavior

An option to specify a key prefix so files could be uploaded in a subfolder.

Justification

I'm not using this plugin for hosting a website but rather for hosting static assets of a Next.js application. If I could specify a static/ key prefix then the deployment would match Next.js file naming convention.

Deep upload paths specified with keyPrefix get resolved incorrectly

This is a:

  • Feature request or change
  • Bug report

Expected behavior

Specifying a deep path in a keyPrefix option (e.g. 'a/b') results in uploading files to <s3-bucket-base-url>/a/b folder.

Actual behavior

Currently when a deep path is specified viakeyPrefix (e.g. 'a/b') files get uploaded to a folder with the name, consisting of a comma-separated parts of the specified path (like 'a,b').

Steps to reproduce

  • Operating system: macOS Mojave
  • serverless-finch version: 2.4.2
  • serverless.yml that produces bug:

Here's the chunk of the serverless.yml file related to the behaviour:

...
plugins:
  - serverless-finch

custom:
  client:
    bucketName: some-bucket-name
    distributionFolder: dist/client/compressed
    keyPrefix: a/b
...
  • Command that produces bug: serverless client deploy

  • Other details:

The root of the problem seems to be here:
https://github.com/fernando-mc/serverless-finch/blob/master/lib/upload.js#L94

We are adding prefix (which is an array) as an element of fileKey array. Elements of fileKey array later get joined with a / separator. (https://github.com/fernando-mc/serverless-finch/blob/master/lib/upload.js#L98)

When .join() is run on a nested array, it converts elements of that array to strings, which results in an undesirable effect with commas in our case:
[['a', 'b'], 'c', 'd'].join('/') // results in 'a,b/c/d'

Here's a codepen illustrating this: https://codepen.io/_olko/pen/bGbpboo

Will create a pull request.

Feature Request: Add custom fields to define index and error documents

It would be nice to be able to define the following config so that a single page application could set them both to 'index.html'. The following config should be defaults if not provided, to not break current implementations.

custom:
  client:
    indexDocument: 'index.html'
    errorDocument: 'error.html'

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.