Copilot-cli: `app pipeline init` experience

[SoManyHs]

Experience

The help menu

$ archer pipeline init -h
Sets up a pipeline for an app in your project with stages that correspond to your app's environment as well as a build environment. Transition to any prod stages will be disabled as default. Uses AWS CodeBuild and AWS CodePipeline.

Usage
  archer pipeline init [flags]

Flags
  --app string                      Name of the application (required)
  --github-repo <string>            Name of the GitHub repository that will trigger the build (required)
  --github-access-token <string>    File with Github personal access token needed to integrate with CodeBuild (required)
  --full-cd <boolean>               Enables transition to prod stages (optional). Defaults to false.
  --deploy <boolean>               Automatically deploys pipeline via CloudFormation
  --environments <list of strings>  Environments (in order) to be added to the pipeline
  -h, --help                        Help for command

Examples
  $ archer pipeline init -n frontend --repo https://github.com/BadGoose/ChaOs --access-token-file ./myGitHubToken.txt

The interactive experience

$ archer pipeline init
? Which application would you like to generate a pipeline for?
> frontend
> backend

? What is the name of your GitHub repository for your application?
https://github.com/BadGoose/ChaOS

? What is your GitHub personal access token?
*********

✔︎ Success! You can start adding stages to your pipeline for: https://github.com/BadGoose/ChaOS 
? Pick an environment to add to your pipeline:
*>** test*
> prod

✔︎ Great, we added your *test* environment as a pipeline stage!
? Would you like to add another environment? y

? Pick an environment to add to your pipeline:
> prod

? Great, we added your *test* environment as a pipeline stage!
? Would you like to add another environment? n

✔︎ Success! Created build project and pipeline for application: frontend with stages: [build, test, prod]
? Would you like to deploy your pipeline? y

⏳Deploying CodePipline-frontend-badGoose-chaOS...

[efekarakus]

yayyy

The help menu

-n, --name string Name of the application (required)

Could we remove this flag? For now if we want to enable the pipeline for a single application we could just error if there are more than 1 app in the workspace. The ideal UX will be to have the pipeline pick up your applications in the ws.

--access-token-file

To be consistent with the interactive experience (which doesn't prompt for a file) should we just let this be a plain string? users could use environment variables maybe if they don't want it to be seen here.

The interactive experience

? Which environments would you like to add to your pipeline?
> test
> prod
> all

What do you think about leveraging's survey's MultiSelect prompt? (to remove the all option)

? What is the name of your GitHub repository for your application?
https://github.com/BadGoose/ChaOS

Can we possibly exec and get outputs from git remote -v to list here? So that the user can select which GitHub repository to use:

? What's your GitHub repository's URL?
> https://github.com/efekarakus/amazon-ecs-cli-v2.git
> https://github.com/aws/amazon-ecs-cli-v2
> Enter custom URL

[SoManyHs]

To be consistent with the interactive experience (which doesn't prompt for a file) should we just let this be a plain string? users could use environment variables maybe if they don't want it to be seen here.

Yeah i'm torn on this. There's nothing that the AWS CLI enforces in this regard for secretsmanager commands, but it seems like maybe not hte best practice to have people put in a plaintext string. i agree it is clunky though. not sure if it is overkill to have --access-token as well as --access-token-file?

[SoManyHs]

+1 om multiselect, though i figured that having an all option streamlines the need to do that

[SoManyHs]

ooh, interesting idea with the git remote -v option, i love it!

[efekarakus]

@allisaurus Any thoughts on the --access-token vs --access-token-file?

I agree I think having both is overkill :P

[SoManyHs]

@efekarakus for the --name flag, would you then just have it required only if there is more than one app in the workspace?

[efekarakus]

I was thinking that if there is more than 1 app in the workspace, the pipeline would deploy all of the applications together in an env.

If that's too much work for the tracer bullet, we can start with throwing an error if the user has more than 1 app in the ws saying that this command is not available yet for more than 1 app.

[sonofachamp]

+1 om multiselect, though i figured that having an all option streamlines the need to do that

Multi-select would also support partial selection if you wanted to exclude an environment for some reason.

---

@efekarakus for the --name flag, would you then just have it required only if there is more than one app in the workspace?

I was thinking that if there is more than 1 app in the workspace, the pipeline would deploy all of the applications together in an env.

Including a --name flag seems like it would be important if we plan to support application specific exclusions or being able to deploy applications individually? Is "pipeline per project" vs. "pipeline per application" decided on, or is there a plan to support both potentially in the future?

[efekarakus]

Including a --name flag seems like it would be important if we plan to support application specific exclusions or being able to deploy applications individually? Is "pipeline per project" vs. "pipeline per application" decided on, or is there a plan to support both potentially in the future?

I believe we want "pipeline per repo"

[hencrice]

A few things I noticed. Probably more will come as we flush out the CFN template rendering part.

1. --name should be the name of the pipeline
2. As Efe said, we want one pipeline per Git repository (i.e. workspace). And I suppose the recommended approach is for a repo to contain only one app for now.
3. We can assume that the branch the pipeline will track is master. But do we want to make it configurable?
4. For non-interactive workflow, should we also ask customers to give us a list of environments in the order they want to deploy to?

[SoManyHs]

Can applications share an environment? If that's the case then that addresses the one application per pipeline scenario.

--name should be the name of the pipeline

should we change --name to be --app instead? (or whatever we're calling it now). I was trying to be consistent with the package and deploy UX, sice I assumed we would generate the pipeline name for you.

We can assume that the branch the pipeline will track is master. But do we want to make it configurable?

Hmm, that's a good point. I assume we're envisioning pipelines/environments to be potentially shared among multiple developers right? So I think it makes sense to default the pipeline to track mainline, though having this be configurable is probably a good idea.

For non-interactive workflow, should we also ask customers to give us a list of environments in the order they want to deploy to?

Great point. I think we need to take this into account for both interactive and non-interactive. Maybe for interactive we can have them add envs in the order they choose?

Need to think a bit more for how to order the environments in the non-interactive flow.

[efekarakus]

Can applications share an environment? If that's the case then that addresses the one application per pipeline scenario.

Yes, that's why we can drop the --app flag.

Maybe for interactive we can have them add envs in the order they choose?

That makes sense to me!

[SoManyHs]

Still might want to add "full-cd" and "deploy" flags.

[efekarakus]

pipeline init is shipped 🚀