You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When projects get created from the CLI astro airflow create, it should make a call to Houston. Houston will need to create a record in the deployments table in postgres, tying it to the users who have access to push to it.
astro airflow ls should just query Houston for the list of deployments the user is able to push to.
NGINX auth needs to be wired up (@cwurtz is on this) so docker pushes (eg astro airflow deploy) are first validated by checking to make sure the user has access to push to that particular deployment.
Definitely agree that astro aiflow deploy should do the query for valid deployments and make it easy for the user to choose.
A user needs to be aware of what projects they have running in the cloud for supplying arguments to deploy.
Suggested Behavior
When a user runs
astro airflow deploy
with no supplied release name, CLI will prompt user with a list of valid release names they have access to.A new command that returns a list of projects (deploys) a user has access to.
astro airflow ls
is a possibilitySPIKE
How much of this should live in houston? Have we drawn lines around what features the CLI wraps vs what houston will wrap?
The text was updated successfully, but these errors were encountered: