Open specious opened 3 years ago
Thanks for the suggestion, we will look into it
Having this validation occur before a deployment is attempted would help avoid a failed deployment and a corresponding rollback. In my testing, if I set a parameter up like so:
Parameters:
MyParam:
Type: String
MinLength: 1
ConstraintDescription: is a required parameter
then running a sam deploy
with this parameter set as an empty string creates a changeset successfully and prompts for deployment. Upon starting to deploy, CloudFormation begins but then fails very quickly, needing to rollback the failed deployment:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ResourceStatus ResourceType LogicalResourceId ResourceStatusReason
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
CREATE_IN_PROGRESS AWS::CloudFormation::Stack MyStack -
CREATE_FAILED AWS::CloudFormation::Stack MyStack Parameter MyParam failed to
satisfy constraint: is a required
parameter
UPDATE_ROLLBACK_IN_PROGRESS AWS::CloudFormation::Stack MyStack The following resource(s) failed to
create: [MyStack].
UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGR AWS::CloudFormation::Stack MyStack -
ESS
DELETE_COMPLETE AWS::CloudFormation::Stack MyStack -
UPDATE_ROLLBACK_COMPLETE AWS::CloudFormation::Stack MyStack -
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Edit: I've encountered this issue again in a slightly different context - expecting that AllowedValues
would be validated at SAM build time. In my case, builds are allowed to proceed - and fail - for resources with invalid parameter values since any value is permitted at this time.
It would be valuable to have immediate parameter value validation upon entry.
For example, a parameter may be defined in
template.yml
(e.g. as per the official documentation for RDS password constraints):It would then be useful to have the value validated against both the implicit constraints and explicitly stated constraints upon entry:
The current behavior is to let the value pass until the deployment initiation phase, at which point the deployment attempt doesn't pass validation:
This is a noticeable inconvenience.