You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When parsing inputs on the cli given by --var, boilerplate will use default YAML parsing rules to guess the type rather than using the type provided in the boilerplate.yml file
To Reproduce
Suppose we have a boilerplate.yml file like this:
- name: AwsLogsAccountIdorder: 4description: Enter the AWS account ID for the logs accounttype: string
You would expect to be able to use a command like the following to provide the AWS account ID:
boilerplate ... --var AwsLogsAccountId=1234567890
This will throw an error saying an integer cannot be treated as a string:
ERROR: Value '9.87654321e+08' is not a valid value for variable 'AwsLogsAccountId' with type 'string'.
Expected behavior
When type is ambiguous, default to the type specified by the user in the boilerplate.yml file
Additional context
Based on an inspection of the code, I suspect this would happen with other yaml types as well, but haven't verified.
As a workaround you can provide the value as a YML string, but this is not expected unless the user knows yaml parsing is being used under the hood:
Describe the bug
When parsing inputs on the cli given by
--var
, boilerplate will use default YAML parsing rules to guess the type rather than using the type provided in theboilerplate.yml
fileTo Reproduce
Suppose we have a
boilerplate.yml
file like this:You would expect to be able to use a command like the following to provide the AWS account ID:
This will throw an error saying an integer cannot be treated as a string:
Expected behavior
When type is ambiguous, default to the type specified by the user in the boilerplate.yml file
Additional context
Based on an inspection of the code, I suspect this would happen with other yaml types as well, but haven't verified.
As a workaround you can provide the value as a YML string, but this is not expected unless the user knows yaml parsing is being used under the hood:
boilerplate ... --var AwsLogsAccountId="'1234567890'"
The text was updated successfully, but these errors were encountered: