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

Configuration warning with serverless 2.3.0 #87

Open
dbanty opened this issue Sep 25, 2020 · 4 comments
Open

Configuration warning with serverless 2.3.0 #87

dbanty opened this issue Sep 25, 2020 · 4 comments

Comments

@dbanty
Copy link

dbanty commented Sep 25, 2020

🐛 Bug description

After updating Serverless from 2.0.0 to 2.3.0, I started receiving this warning:
Configuration warning at 'provider.runtime': should be equal to one of the allowed values [dotnetcore2.1, dotnetcore3.1, go1.x, java11, java8, java8.al2, nodejs10.x, nodejs12.x, provided, provided.al2, python2.7, python3.6, python3.7, python3.8, ruby2.5, ruby2.7].

🤔 Expected Behavior

There would be no warnings from serverless when using the example config for this plugin.

👟 Steps to reproduce

Use provider.runtime = rust in your serverless.yml with the latest Serverless.

🌍 Your environment

serverless version: 2.3.0
rust-plugin version: 0.3.8

@atridgedcosta
Copy link

Here is a reference to the issue https://www.serverless.com/framework/docs/configuration-validation/

In my case, everything still deployed and worked as expected.

@mosen
Copy link

mosen commented Apr 7, 2021

I did add some config validation on my fork, but although configSchemaHandler does do some limited merging via Object.assign(), it does not merge the enum prop of definitions.awsLambdaRuntime.enum which would be required to make rust a valid option?

I did successfully add validation for the custom.rust section though.

@softprops
Copy link
Owner

Interesting. This plugin relied on the previous flexibility of the config file to deterministically know which functions targeted rust and which don’t through the runtime setting.

In processing a command it gets wired back to the provided runtime so serverless cli does the right thing for its internal tasks

one option might be the option mentioned in the link you posted and setting the validation mode off

configValidationMode: off

Since that’s not a default that can be cumbersome. The tradeoff there is there are other things config validation affords you. If there weren’t it wouldn’t be on by default

im open to other options

@mosen
Copy link

mosen commented Apr 7, 2021

Maybe I'll suggest to whomever is looking at the serverless AWS provider that they standardise their own extension of available runtimes. It doesn't make sense to have the json schema altered for every additional custom runtime.

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

Successfully merging a pull request may close this issue.

4 participants