try pulling an image even if docker login fails

[emily-shen]

Fixes CC-6472

Previously the only image registry allowed was the cloudflare managed one, and the only way to auth with that was to query the containers api for credentials. So we always did that before pulling an image. The vite plugin (for various reasons) couldn't call that api, so registry uris didn't work at all with the vite plugin.

Now we support some external registries, which users could authenticate with directly using docker login, so let's try pulling the image anyway even if calling our API fails. The API might return (short-lived) credentials for external registries if this has been previously configured via wrangler contaienrs registries configure, so it is worth trying to call it still.

The cloudflare-managed registry still wont work with the vite plugin as the only way to get credentials for that is via our API, so this PR also adds a more helpful error message in that case.

Also note that I'm not sure if it is worth adding CI tests for this, since it would involve having to set up a wrangler AWS or dockerhub account to run those tests, and storing secrets for that on this github repo, and introducing a likely spot for flakes.

However, i have tested this manually by:

1. pointing a wrangler config to an ECR image
2. logging in using docker login
3. running wrangler dev and vite dev

---

• Tests
  • Tests included
  • Tests not necessary because: see description
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: bugfix
• Wrangler V3 Backport
  • Wrangler PR:
  • Not necessary because: containers

[changeset-bot]

🦋 Changeset detected

Latest commit: 258e5be

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@11360

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@11360

miniflare

npm i https://pkg.pr.new/miniflare@11360

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@11360

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@11360

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@11360

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@11360

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@11360

@cloudflare/workers-utils

npm i https://pkg.pr.new/@cloudflare/workers-utils@11360

wrangler

npm i https://pkg.pr.new/wrangler@11360

commit: 258e5be

[nikitassharma]

domain not configured I think?

And if so, are we okay with local dev working for something that won't work in prod?

[emily-shen]

whoops yes i forgot to finish that sentence. :') but yes exactly.

I think this is equivalent to being able to local dev with kv etc. but not have created the kv yet. So that wouldn't work at deploy, but with kv etc. we do have a nice flow that provisions KV for you at deploy time.

What we could do is check if you can get the creds at deploy time, and if you can't then run the user through the registries configure flow.

Alternatively, I could make the fall back only happen for vite.

[nikitassharma]

What we could do is check if you can get the creds at deploy time, and if you can't then run the user through the registries configure flow.
I like this idea, feels like it would be useful for more than just local dev -> deploy workflow

[nikitassharma]

okay I was thinking about this more and I'm not sure this would work with public images. especially with docker, we have no way to differentiate public and private images from domain