@yetanothertool/serverless-version-to-ssm v1.0.0

About

This simple plugin extract the lambda version from a serverless framework template.
The goal is to save that version in SSM directly.

Usage

npm install --save-dev @yetanothertool/serverless-version-to-ssm

This plugin uses the function name to determine what resource to replace. The SSM resource name must follow this naming schema:

<functionName>SSM

The value will be overriden with : !Ref <FunctionName>LambdaVersion<RandomId>

To troubleshoot your can use --verbose to see which resources are skipped.

Example:

sls package --stage dev --verbose

✔ Found Matching SSM for 'authorization'
✔ Found Matching SSM for 'originRequest'
✔ Found Matching SSM for 'originResponse'
✔ Found Matching SSM for 'viewerRequest'
Warning: No SSM found for 'viewerResponse'

Example

service: service-name
frameworkVersion: "3"

plugins:
  - "@yetanothertool/serverless-version-to-ssm"

custom:
  #...

provider:
  #...
  lambdaHashingVersion: 20201221
  versionFunctions: true
  #...

package:
  #...

functions:
  authorization:
    handler: authorization/index.handler
    #...

  originRequest:
    handler: originRequest/index.handler
    #...

  originResponse:
    handler: originResponse/index.handler
    #...

  viewerRequest:
    handler: viewerRequest/index.handler
    #...

  viewerResponse:
    handler: viewerResponse/index.handler
    #...

resources:
  Resources:
    #...

    authorizationSSM:
      Type: AWS::SSM::Parameter
      Properties:
        Name: /${self:custom.tenant}/lambda-edge/authorization/version
        Type: String
        Value: "will_be_replaced_by_the_plugin"
        Description: Latest lambda@edge version for CloudFront

    originRequestSSM:
      Type: AWS::SSM::Parameter
      Properties:
        Name: /${self:custom.tenant}/lambda-edge/originRequest/version
        Type: String
        Value: "will_be_replaced_by_the_plugin"
        Description: Latest lambda@edge version for CloudFront

    originResponseSSM:
      Type: AWS::SSM::Parameter
      Properties:
        Name: /${self:custom.tenant}/lambda-edge/originResponse/version
        Type: String
        Value: "will_be_replaced_by_the_plugin"
        Description: Latest lambda@edge version for CloudFront

    viewerRequestSSM:
      Type: AWS::SSM::Parameter
      Properties:
        Name: /${self:custom.tenant}/lambda-edge/viewerRequest/version
        Type: String
        Value: "will_be_replaced_by_the_plugin"
        Description: Latest lambda@edge version for CloudFront

    ViewerResponseSSM:
      Type: AWS::SSM::Parameter
      Properties:
        Name: /${self:custom.tenant}/lambda-edge/viewerResponse/version
        Type: String
        Value: "will_be_replaced_by_the_plugin"
        Description: Latest lambda@edge version for CloudFront

Contributing

1. Create a Feature Branch
2. Commit your changes
3. Push your changes
4. Create a PR

Branch Checkout:

git checkout -b <feature|fix|release|chore|hotfix>/prefix-name

Your branch name must starts with feature|fix|release|chore|hotfix and use a / before the name; Use hyphens as separator; The prefix correspond to your Kanban tool id (e.g. abc-123)

Keep your branch synced:

git fetch origin
git rebase origin/master

Commit your changes:

git add .
git commit -m "<feat|ci|test|docs|build|chore|style|refactor|perf|BREAKING CHANGE>: commit message"

Follow this convention commitlint for your commit message structure

Push your changes:

git push origin <feature|fix|release|chore|hotfix>/prefix-name

Examples:

git checkout -b release/v1.15.5
git checkout -b feature/abc-123-something-awesome
git checkout -b hotfix/abc-432-something-bad-to-fix

git commit -m "docs: added awesome documentation"
git commit -m "feat: added new feature"
git commit -m "test: added tests"

License

Distributed under the MIT License. See LICENSE for more information.

Contact

• Tommy Gingras @ tommy@studiowebux.com