Clarification around "copilot svc deploy" command

[tsingh2k15]

I was looking at the docs for copilot svc deploy command and was curious to understand/explore more about the steps it performs. https://aws.github.io/copilot-cli/docs/commands/svc-deploy/

My question is around step 1 - Build your local Dockerfile into an image

Does it always build the container image from Dockerfile even if the image might be already built independently before this step? I know there is a mutually exclusive option in the manifest file - https://aws.github.io/copilot-cli/docs/manifest/backend-service/#image-location but I was curious to check if the deploy command can have an alternative mode where it could just tag an already built image and perform remaining steps by skipping step 1?

[huanjani]

Hello, @tsingh2k15!
Interesting question! I'm curious what your use case for this ask. How would Copilot locate the built container image?
Thanks!

[tsingh2k15]

@huanjani Thank you for looking into my question. I am running into a scenario which is specific to the CI/CD workflow and AWS environments at my end. But I do believe that this scenario I am running into could also occur in other projects where cross account access is restricted or similar workflow is used.

Scenario and thoughts:

I have a CI/CD pipeline (Jenkins based), where I am using copilot for all of my containerized applications on ECS Fargate. When CI happens in "dev" environment and things go well in "dev" where it deploys fine in "dev". Then, I have a workflow where I would deploy the code to upper environment. I use different AWS accounts for each environment. I have a common AWS CodeArtifact repository in "dev" account, in future I may move it to a common AWS account(dedicated to AWS CodeArtifact management). As part of copilot svc deploy, my Dockerfile will build the image by pulling/installing the code from CodeArtifact. This works fine if the copilot deploy is also running in the same account as CodeArtifact repo, so access to pull/read artifacts is allowed. But, if the same copilot deploy command runs in upper environment, access is denied there, so it fails on step 1 of building the image. Also, I do not want my workflow to pull the artifact from CodeArtifact in a lower environment("dev") when it deploys to an upper environment. On the other hand, it is also not a simple approach to have separate CodeArtifact repos in each account. I know this is more of an access issue at this point, and as I have mentioned that I may have a common dedicated AWS account for artifact management in future, where I may allow read access from other accounts, so the copilot deploy would succeed in any account with that architecture. But, on another thought, I am thinking that why would I re-build the image again and again on my CI server, if it is already built, then copilot could just tag it and then proceed with next steps of deployment.

Let me know if further clarification is needed on above scenario. There are two aspects to it:
1: My current situation of cross account access denied to CodeArtifact. My plan is to have a common AWS account for artifact management. So this won't be an issue in near future where I would allow read access from other accounts.
2: Building the image multiple times. This is a general question, not specific to my scenario; I would like to just build the image once in "dev" on my CI server and apply different tags for each upper environment as I promote the deployment to upper environments.

Hence, I believe, it could be helpful if the first step in copilot svc deploy command could be enhanced such that if a user specifies the image name(possibly located on local CI server), then copilot can use that image and tag it to proceed with next steps of deployment?

I know this could be very specific to my scenario. So I am just throwing my thoughts here. There is no specific usecase for this. I am thinking of short term workarounds and long term solutions at my end, and thought I can also ask for more thoughts here.

[tsingh2k15]

thank you @huanjani for considering this improvement. I have created an issue out of this discussion - #3163