Sam Package/Deploy --image-repository Behavior

Many of the process I put in place for both open source and in company deploy pipelines take advantage of SAM CLI and the AWS CLI using conventions like AWS_PROFILE. I’ve been very happy that SAM CLI has followed these patterns. Today when working with the new container features I was surprised by this odd behavior of sam package when using the --image-repository option. Here is an example of my usage where the new image repo was added to my process.

sam package \
  --region ${AWS_DEFAULT_REGION} \
  --template-file ./.aws-sam/build/template.yaml \
  --output-template-file ./.aws-sam/build/packaged.yaml \
  --image-repository  "lambyc-starter" \
  --s3-bucket "${CLOUDFORMATION_BUCKET}" \
  --s3-prefix "lambyc-starter-${RAILS_ENV}"

These commands are run as either the default AWS_PROFILE or with specific ENV overrides. Given this was set and that the --region was set here, my expectation was this command was going to find and publish to the ECR repo within my AWS account. Instead, it tried to push to docker.io and failed with a user password. Digging into some guides and published SAM examples I can see what you expect folks to do is:

sam package \
  --region ${AWS_DEFAULT_REGION} \
  --template-file ./.aws-sam/build/template.yaml \
  --output-template-file ./.aws-sam/build/packaged.yaml \
  --image-repository  "123456789.dkr.ecr.us-east-1.amazonaws.com/lambyc-starter" \
  --s3-bucket "${CLOUDFORMATION_BUCKET}" \
  --s3-prefix "lambyc-starter-${RAILS_ENV}"

This feels like the wrong interface to me and against the grain of how the CLI operates given all my previous experiences. I can work around this if y’all disagree by adding more aws CLI commands to find the account ID and use the AWS_DEFAULT_REGION env and/or look that up as well. But it would cool if SAM did this. Thoughts?

[solarmosaic-kflorence]

I am confused by --image-repository as well. In some contexts, it seems like it should be optional (for example, when you are using sam deploy with a packaged template that already includes the full ImageUri to a tagged ECR image).

[PikaChokeMe]

I found this issue after trying to make a docker image and being told I need to specify a --image-repository. I was hoping to be able to use something as simple as --resolve-image-repository similar to the --resolve-s3 option, but it seems to be much much more difficult than that.

I tried to make a script which does the following

aws ecr create-repository --repository-name "my-project" || true

AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
AWS_DEFAULT_REGION=us-west-2
IMAGE_REPOSITORY="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/my-project"

and then specified --image-repository "$IMAGE_REPOSITORY", which only leaves me lost, confused, and frustrated with the following error

Error: Unable to upload artifact None referenced by ImageUri parameter of CustomLambdaFunction resource.
Image not found for ImageUri parameter of ManageOktaAppsLambdaFunction resource.

All I really have to add is that I agree that all the extra setup/requirements to get this all up and running seems very anti SAM. So far SAM has done an extremely good job at being easy for even a novice with limited AWS cloud formation knowledge like me to figure out. This is the first time I feel like SAM doesn’t just work, and it’s been very frustrating.