astronomer / astro-cli / 39077154563

45%

push

github

Reject embedded image tags in remote.client_registry (#2224)

* Reject embedded image tags in remote.client_registry

astro remote deploy appends its own ":deploy-<timestamp>" tag to
whatever value is configured for remote.client_registry. If a user
sets that value to a full tagged image reference (e.g. copy-pasted
from a Dockerfile FROM line), the CLI produces a double-tagged
reference like "registry/repo/image:1.0:deploy-2026-07-22T16:23",
which Docker rejects with an opaque "invalid reference format" error.

ValidateRegistryEndpoint now rejects any value whose repository path
(the portion after the first "/") contains a ":", while still
allowing a ":port" on the registry host itself.

Fixes #2223

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* Check the registry endpoint with Docker's grammar, and where it is used

From a code review of this PR:

- The check ran only when remote.client_registry was set, so a value
  saved with a tag before it existed, or written into config.yaml by
  hand (the customer's case in #2223), still reached Docker as
  "invalid reference format". astro remote deploy now checks the
  value before building, and astro dev init checks a saved value
  before saving it into the project, each saying how to fix it.
- The check looked for a ':' after the first '/', which let through an
  uppercase name, a '@' with no digest and a port that is not a
  number, and called a digest a tag. It now parses the endpoint with
  github.com/distribution/reference, Docker's own grammar, which the
  CLI already uses: a tag and a digest are each refused with their own
  message, and anything else Docker would reject is refused with
  Docker's reason.
- The DeployClientImage tests set the registry to test-registry:latest,
  no repository and a tag, and one asserted the double-tagged
  reference this PR exists to prevent; they use a real repository now.

Tests: tags with and without a port, a digest, uppercase, a '@' with no
digest and... (continued)

38 of 40 new or added lines in 3 files covered. (95.0%)

27378 of 60519 relevant lines covered (45.24%)

9.97 hits per line