When I specify cache_from as referring to an ECR registry/image/tag I get the following:
Error response from daemon: Get https://<id>.dkr.ecr.<region>.amazonaws.com/v2/<image>/manifests/latest: no basic auth credentials Could not pull cache-from image <id>.dkr.ecr.<region>.amazonaws.com/<image>:latest. Ignoring...
Would I be correct in assuming that cache_from is implemented purely in the Docker base image and not aware of authentication methods of ACR, ECR, GCR and Heroku? If so, should I open an issue against https://github.com/drone-plugins/drone-docker?
I am new to Drone, so it’s also entirely possible I’ve just done something stupid and misconfigured something.
the plugin uses the ECR API to generate a docker username and password, which is then provided to the standard docker login command . The docker client and --cache-from commands are executed after the login, and therefore have access to the authentication credentials .
The error you posted could indicate secrets were not properly passed to the plugin. So it is unclear there is any issue with the plugin itself. The full logs for the step would provide more details. But either way, I recommend reading through the code to understand how the plugin works, and sending a patch if you think improvements can be made.
EDIT:Sorry, that config doesn’t match the screenshot above (i.e. two build steps vs one). However, I’ve got many projects that are all failing and missing logs. I presume they’re all failing their ECR upload due to the aforementioned lack of credentials. However, I can’t see the logs unless I actually sit there monitoring them - they’re not persisted post-build.
Running in Kubernetes and some secrets are at least being created, because initially I misconfigured my cluster role and got an error - fixed that and the error went away.
Anyway, I’ll keep digging and report back once I’ve got something more useful to go by.
Okay, it was indeed a case of the stupids. I missed specifying region in my config. Also, had my tag env var substitution syntax incorrect (not sure where I got that syntax from).
Although, the default behavior presently isn’t spelled out all that clearly in the docs, and I think it could be improved.
Specifically, both region and registry can typically be pulled from repo. To my knowledge, the only time this wouldn’t be possible is if someone were to use the ECR plugin with a third-party ECR-compatible (but not ECR) registry, assuming such a thing exists.
If I can wrap my head around this whole Go thing; would you be open to PR that matches repo against ^([^.]+\.dkr\.ecr\.([^.]+)\.amazonaws\.com)/.+ and when such a match occurs assigns $1 to registry and $2 to region?
User specified registry and region would still take precedence. Although I can’t imagine circumstance whereby they’d differ - could perhaps print a warning if such a case does arise.