Assuming ownership of previously orphaned ECR repositories

[rcdailey]

I have an ECR repository with an explicit name and and a RemovalPolicy of RemovalPolicy.RETAIN. The reason for the explicit name is so that I can push to this ECR repository from my CI/CD pipeline when it creates a docker image for my application. I set the removal policy to "retain" because if this stack is manually destroyed, I do not want to lose the previously uploaded docker images.

There's an issue, though. When I re-run cdk deploy, it fails because those ECR repositories already exist. What I'd like, though, is for the CDK to re-assume ownership of those retained and orphaned ECR repositories. I do not see a way to codify this. I have to choose to either manually create these ECR repositories and import them in the CDK, or delete them and have the CDK re-create them which destroys the previously uploaded docker images.

Could the contributors here recommend an approach that allows the CDK to maintain ownership and management of these ECR repositories while at the same time retain images in the ECR repositories themselves?

[seriteatmea]

thanks you for sharing, very interesting

[peterwoodworth]

@github-actions proposed-answer You can use cdk import, which makes use of the CloudFormation import feature. ECR::Repository is a supported resource for importing, so this should work. Be sure to follow the instructions in the cdk import documentation, and please open up an issue if you encounter any bugs

[github-actions[bot]]

Hello! A team member has marked the above comment as the likely answer to this discussion thread. If you agree, please upvote that comment, or click on Mark as answer. I will automatically mark the comment as the answer next time I check. If this answer does not help you, please downvote the answer instead and let us know why it was not helpful. I will add a label to this discussion to gain attention from the team.

[rcdailey]

I guess import is the only solution available at the moment. I would prefer there be a way to codify this so a separate, additional command is not necessary. The linked documentation is also unclear on the point of "A template that describes the entire stack, including both the original stack resources and the resources you're importing.".

Thank you for taking the time to share your response.

[peterwoodworth]

I'm not sure how this would work codified, could you explain how that might work? This is a one time operation that depends on the current state of your AWS account, I think it works better as a CLI operation because CDK/CloudFormation is declarative.

A template that describes the entire stack, including both the original stack resources and the resources you're importing.

It means you need to have a template, and it needs to include the resource you intend to import into your stack. "Original stack resource" means that you can have other resources in your stack that are already defined and deployed through the stack.

[Cameron5y]

Good work)

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.