Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

export fails when using variables #37

Open
eparry opened this issue Jul 30, 2019 · 1 comment
Open

export fails when using variables #37

eparry opened this issue Jul 30, 2019 · 1 comment

Comments

@eparry
Copy link

eparry commented Jul 30, 2019

When exporting with variables it complains that "Invalid variable reference syntax for variable AWS::Partition. You can only reference env vars, options, & files. You can check our docs for more info.". In my case variables are: provider.stage = ${opt:stage, 'dev'}, and then ${self:provider.stage}. If I remove those and hardcode it is fine. Here is my serverless template:

service: document

provider:
  name: aws
  runtime: nodejs10.x
  memorysize: 64
  region: ca-central-1
  stage: ${opt:stage, 'dev'}
  # Environment vars - access using process.env.DB_HOST inside lambda
  environment:
    DB_USERNAME: ${ssm:/${self:provider.stage}/rds/masterusername}
    DB_PASSWORD: ${ssm:/${self:provider.stage}/rds/masterpassword~true}
    DB_NAME: {"Fn::ImportValue": "${self:provider.stage}-DBName"}
    DB_HOST: {"Fn::ImportValue": "${self:provider.stage}-DatabaseEndpoint"}
  # This installs the lambda inside our VPC
  vpc:
    securityGroupIds:
      - {"Fn::ImportValue": "${self:provider.stage}-LambdaSecurityGroup"}
    subnetIds:
      - {"Fn::ImportValue": "${self:provider.stage}-PrivateSubnet1a"}
      - {"Fn::ImportValue": "${self:provider.stage}-PrivateSubnet2a"}
  # security statements to run in a vpc. can also add S3 policy statements here
  iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "ec2:CreateNetworkInterface"
        - "ec2:DescribeNetworkInterfaces"
        - "ec2:DeleteNetworkInterface"
      Resource: "*"
  timeout: 15
  deploymentBucket:
    name: my-serverless-deployments # this is where sls uploads a zip file to containing the lambda

functions:
# This defines the "list" endpoint inside handler.js
  list:
    handler: handler.list
    events:
      - http:
          path: /entity/{entityId}/documents # added to the end of the address
          method: get
          integration: lambda-proxy # automatically configures API gateway
          cors: true # allows you to hit the endpoint from our front end app (eg localhost:3000)
          # adds an authorization check to the lambda, so that you can only call it using a token. comment it out 
          authorizer:
                type: COGNITO_USER_POOLS
                authorizerId:
                  Ref: ApiGatewayAuthorizer

plugins:
  - serverless-domain-manager
  - serverless-sam

# defines the API gateway authorizer, which checks for a token
resources:
  Resources:
    ApiGatewayAuthorizer: 
      Type: AWS::ApiGateway::Authorizer
      Properties: 
        AuthorizerResultTtlInSeconds: 300
        IdentitySource: method.request.header.Authorization
        Name: my-dev-authorizer
        RestApiId: 
          Ref: "ApiGatewayRestApi"
        Type: COGNITO_USER_POOLS
        ProviderARNs: 
          - 'arn:aws:cognito-idp:ca-central-1:011305767231:userpool/ca-central-1_yfYsmCVO4'

@disbelief
Copy link

I'm also seeing several places where serverless variables are included in the SAM template that gets outputted. Sadly this makes the plugin pretty unusable for my/most non-trivial use cases.

Is this a recent regression, or were serverless variables never supported?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants