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

[Bug][Compose] #149

Open
4 tasks done
darylteo opened this issue Jul 21, 2022 · 5 comments
Open
4 tasks done

[Bug][Compose] #149

darylteo opened this issue Jul 21, 2022 · 5 comments
Labels
enhancement New feature or request needs feedback

Comments

@darylteo
Copy link

Are you certain it's a bug?

  • Yes, it looks like a bug

Is the issue caused by a plugin?

  • It is not a plugin issue

Are you using the latest v3 release?

  • Yes, I'm using the latest v3 release

Is there an existing issue for this?

  • I have searched existing issues, it hasn't been reported yet

Issue description

In serverless-compose.yml, param placeholders do not have the same "default value" functionality that is available in the general serverless.yml

https://github.com/darylteo/serverless-compose-bug-repro

In this reproduction repo, I have 2 services - 1 for the api functions, another for Cloudformation StackSet. I need to pass the RoleARN from the schema service over to the api service. This works once running sls deploy but in environments where I cannot do this (developer environments without access keys to remote AWS accounts), it fails to retrieve the ARN as the ARN does not exist yet.

I definitely do not want to make it a requirement for every developer to have to do a deploy before they can perform any changes. So I expected to be able to use the default value template pattern to solve this but it seems that serverless-compose.yml does not support this, and insteads just passes the entire placeholder as is.

As is, I cannot run the service offline using serverless-offline, and I cannot run any offline unit tests, without actually doing a deploy first.

I understand this is a beta, and I may have missed something perhaps. If so please let me know!

Appreciate the package.

Service configuration (serverless.yml) content

serverless-compose.yml

services:
  api:
    path: api
    params:
      # does not work - default value does not pass through
      LambdaRoleArn: ${schema.LambdaRoleArn, ''} # runs but entire placeholder is treated as string
      
      # does not run - The variable "${schema.LambdaRoleArn}" cannot be resolved: the referenced output does not exist. 
      # LambdaRoleArn: ${schema.LambdaRoleArn} 
      

      # here to show that params are working
      PassedParam: "Hello World"


  schema:
    path: schema

Command name and used flags

sls api:invoke local --function hello

Command output

{
    "statusCode": 200,
    "body": "{\n  \"message\": \"Value: ${schema.LambdaRoleArn, ''} and param is Hello World\",\n  \"input\": \"\"\n}"
}

Environment information

> sls --version
Running "serverless" from node_modules
Framework Core: 3.21.0 (local) 3.21.0 (global)
Plugin: 6.2.2
SDK: 4.3.2
@pgrzesik
Copy link
Contributor

Hey @darylteo - thanks a lot for reporting and sorry you've run into trouble.

That's true, currently default fallback is not supported for Compose params - they work a bit differently than params in individual services. It's definitely something to consider moving forward

cc @mnapoli

I'm going to transfer the issue to compose repo, let's continue discussion there

@pgrzesik pgrzesik transferred this issue from serverless/serverless Jul 21, 2022
@pgrzesik pgrzesik added enhancement New feature or request needs feedback labels Jul 21, 2022
@mnapoli
Copy link
Contributor

mnapoli commented Jul 21, 2022

👍 that sounds like a reasonable improvement indeed. @pgrzesik do you think that would be easy to implement?

Also I'm curious:

I understand this is a beta

Compose is no longer in beta, would you be able to tell us what made you think that? Maybe we have some piece of documentation that we need to update.

@pgrzesik
Copy link
Contributor

I think that should be possible to implement without too much effort

@darylteo
Copy link
Author

@mnapoli I'm not... actually sure why I thought it was beta. But I know it was released in April so perhaps I assumed you were still working out the kinks :)

@pgrzesik sounds great. Thank you!

@darylteo
Copy link
Author

darylteo commented Aug 8, 2023

Hi Team, wondering what happened with this? Is this still something that could be added in the future? 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs feedback
Projects
None yet
Development

No branches or pull requests

3 participants