Fixed an issue lambda deploy-serverless command tries to build image when ImageUri is set in template without any Metadata.

[ashishdhingra]

Issue #, if available: #264

Description of changes: Fixed an issue lambda deploy-serverless command tries to build image when ImageUri is set in template without any Metadata.

Per https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-imageuri, Building your application with necessary Metadata entries takes precedence over ImageUri, so if you specify both then ImageUri is ignored..

In customer reported scenario, metadata is not present in YAML (orJSON) template. In such case, it should not try to build the Docker image locally, instead should use the ImageUri set in the CloudFormation template. Currently, before this fix, it tries to validate the ImageUri as local path and fails the validation check.

NOTE: We could have added a validation check to verify if image pointed out by the ImageUri exists in ECR, however, there is no API to get image by ImageUri.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[ashishdhingra]

We are going to need a test that we can use a template that has an image uri set to an already pushed image.

@normj Added tests for YAML and JSON template.

Could you please advise on the following:

• Possible 2 ways of specifying ImageUri:

  • The link https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-imageuri mentions ImageUri (and CodeUri) as top level template properties.
  • Whereas, https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html specifies ImageUri nested inside top level code Code property. There is no CodeUri property.

  Which one is correct? Or both are supported? If yes, why 2 different ways of specifying ImageUri. Should we also test with nested ImageUri property template as well?

• During testing, I noticed that the cleanup DeleteServerlessCommand when executed without specifying the Region (in this case it would use the default region from the profile), even though was successful, but it was not deleting CloudFormation stack. The reason is that we use TEST_REGION (sa-east-1) while creation of stack and other resources, whereas the DeleteServerlessCommand was picking up some other region from my profile. Changing cleanup code to explicitly set Region as TEST_REGION actually initiated the stack deletion. This cleanup code was copied from existing test. It's highly likely that such existing test(s) might not be actually cleaning (deleting) up the stack. Should we review such cleanup code and correct it as part of this PR?

Thanks, Ashish