`astro auth login -d [domain]` Should Override Registry Config if Exists about astro-cli HOT 3 CLOSED

@cwurtz @schnie How much custom configuration do we want to support with the registry host?

With the introduction of houston we are now managing the authentication to two separate hosts. In a base installation we can rely on the registry existing at registry.[baseDomain] which makes the RegistryAuthority config redundant.

I could see a use case where a user may want to point to a registry that exists at a different url. This makes the management of these two configurations complicated. I could go into more detail about the specifics, but the gist is that managing these two configurations adds to some complexities in the reconciliation of these two settings on gets and sets.

IF we want to support custom registry locations we have two options from what I can tell

• muddy up the astro auth login command to have robust support for setting RegistryAuthority and CloudDomain at both project and global levels
• move registry location to a value stored in houston and returned when authenticating to houston which can then be passed to the docker auth we do behind the scenes

from astro-cli.

@andscoop is this an issue for anybody yet?

from astro-cli.

@schnie The issue that this ticket was created for has affected me and I'm guessing it will affect more as we continue to upgrade and develop the platform. I wouldn't call it critical because it's easily resolved with a config.yaml change.

One intermediate solution would be to prompt user with each call astro auth login with the domain we authenticating to.

from astro-cli.