3 ms·
On top of that, it's either the OCI spec that's broken or it's just AWS being nuts, but unlike GitLab and Nexus, AWS ECR doesn't support automatically creating
by mschuster91 2y ago
On top of that, it's either the OCI spec that's broken or it's just AWS being nuts, but unlike GitLab and Nexus, AWS ECR doesn't support automatically creating folders (e.g. "<acctid>.dkr.ecr.<region>.amazonaws.com/foo/bar/baz:tag"), it can only do flat storage and either have seriously long image names or tags.
Yes you can theoretically create a repository object in ECR in Terraform to mimic that behavior, but it sucks in pipelines where the result image path is dynamic - you need to give more privileges to the IAM role of the CI pipeline than I'm comfortable with, not to mention that I don't like any AWS resources managed outside of the central Terraform repository.
[1] https://stackoverflow.com/questions/64232268/storing-images-in-aws-ecr-using-namespaces https://stackoverflow.com/questions/64232268/storing-images-...
- hanikesn 2y agoThat's seem standard AWS practice. Implement a new feature so you can check the box, but in practice it's a huge pain to actually use.
- xyzzy_plugh 2y agoIIRC it's not in the spec because administration of resources is out of scope. For example, perhaps you offer a public repository and you want folks to sign up for an account before they can push? Or you want to have an approval process before new repositories are created? Regardless it's a huge pain that ECR doesn't support this. Everybody I know of who has used ECR has run into this. There's a long standing issue open which I've been subscribed to for years now: https://github.com/aws/containers-roadmap/issues/853 https://github.com/aws/containers-roadmap/issues/853