Copilot-cli: archer init usability overhaul

[kohidave]

Init is powerful, but currently pretty confusing to new customers. We should spruce up init to do a better job of explaining concepts, what it's doing and next steps.

• [x] We need to explain what an project, application and environment are #126
• [x] Guide folks on where to run this command #132
• [x] After we ask someone if they want to deploy a test env, we should tell them that they can do it later by running env add #152 #151
• [x] Tell folks what we're going to do, when we're going to create a workspace, and provide feedback once we've done it #111
• [x] Rather than just not asking for a project when you're in a workspace we should say "Looks like you're already in workspace for project _myproject_. We'll use that as your project." #63 #143 #130
• [x] Let folks create a new project if they're not in an existing ws, but there are existing projects in ssm #134

[kohidave]

Some iterations might be more like:

archer init
Note: It's best to run this command in the root of your workspace
Welcome the the ECS CLI! We're going to walk you through some questions to help you get set up
with a project on ECS. A project is a collection of containerized applications (or micro-services) 
that  operate together. 

_If they don't have any projects_

Looks like you don't have any projects already. Let's create one - what would you like to call your 
project? 

_If they have projects in their account but not locally_

Looks like you have some projects already, would you like to create a new app in one of your 
existing projects? 

_Yes_

Ok, here are your existing projects. Select the one you want to add a new application to. 
> DavidLovesPonies
> BadGoose

_No_

Ok, let's create a new one then. What would you like to call your new project?

_If they're in an existing workspace_

Looks like using a workspace that's registered to project _project name_. We'll use that as your project. 

All right, let's set up an application. Your application is the actual service we'll deploy. To help you 
get started, select the type of application you'd like to build from our list of application patterns:
> Loadbalanced Fargate Service

What do you want to call this Loadbalanced Fargate Service? 

Ok great, we'll get you all set up. 
✅ Created a local ecs-config directory './ecs-config'
✅ Wrote the app manifest for _app_ at './ecs-config/frontend-app.yml'

All right, you're all set for local development. Would you like to deploy a staging environment? You can deploy your new application into this staging environment later? [y/N]

_If they do_
spinner
_If they don't_

No prob, you can add a test environment later with `archer env add test`

[efekarakus]

That's pretty good!

We should think what the corresponding flags would look like too for this workflow.

[efekarakus]

My suggestions:

-p, --project   [name]        Name of the project (required).
-a, --app       [name]        Name of the application (required).
-t, --app-type  [name]        Type of the application (required).
--deploy        [bool]        Deploy your application to a test environment (required).

Validation for these flags:

If project is set:
  - If they're in a workspace and the name is different -> error
  - Otherwise, check if the project name exists in the list of existing projects -> notify that they selected a correct name
  - Otherwise, create a new project.

If app name is set:
  - Validate that it matches our app name pattern.
If app type is set:
  - If type is not in the list -> Error

Otherwise, acknowledge the app with its name and type.

Since we're prompting for all these options, then they have to be (required).

[kohidave]

--deploy        [bool]        Deploy your application to a test environment (required).

The --deploy is still tricky. if --deploy took a y/n flag - then there'd be no ambiguity, but as it is, If someone doesn't provide a --deploy flag, we don't know if they don't want to deploy or if we should prompt them.

I think based on some of the feedback from the bug-bash yesterday, folks would like to be able to run init without creating any env infrastructure.

[efekarakus]

Right sorry, when I wrote --deploy [bool] that meant that they have to write --deploy true. Otherwise, we would prompt.

But as I typed it I realized how weird it is.

Maybe we provide two flags instead:

--deploy               Deploy your application to a test environment (exclusive with --no-deploy).
--skip-deploy          Skips deploying your application (exclusive with --deploy).

I don't know if there is a better way of phrasing the conditional piece.

[kohidave]

I love ponies

[efekarakus]

Ended up with the following help menu:

$ archer init -h
Create a new ECS application

Usage
  archer init [flags]

Flags
  -a, --app string        Name of the application.
  -t, --app-type string   Type of application to create.
      --deploy            Deploy your application to a "test" environment.
  -h, --help              help for init
  -p, --project string    Name of the project.

If the user doesn't explicitly set the --deploy flag then we prompt. To avoid prompting, the user can specify it with --deploy=false or --deploy=true