Amplify-cli: (cli@multienv) Amplify init should check for duplicate environment names

[rdickert]

Describe the bug

amplify init allows duplicate environments to be created locally that will fail on first amplify push. Ideally, it should detect this and fail on init.

To Reproduce
Steps to reproduce the behavior:

1. create an environment on a branch (using the beta version of amplify) and amplify push. Choose a name for the environment, say "dupenv"
2. git checkout master (without merging the other branch)
3. create a new branch, amplify init, and choose "dupenv" (or the same as you chose before) as the env name. Operation succeeds
4. amplify push - this will fail with an error including something like:

CREATE_FAILED      S3Bucket...
projectname-20190103155640-hostingbucket-dupenv already exists

Expected behavior
Amplify should be able to detect this issue and fail on step 3 (init) with a more helpful error: "that environment name is already in use in stack arn:xxxx...". If you want to go further, amplify could offer to import the environment.

Additional context
This will only occur between unmerged branches. It is more likely if a developer wants to create an environment that they can reuse or in the context of learning amplify itself.

This might fit work-wise with #2364, which also relates to environment name validation.

[jkeys-ecg-nmsu]

@kaustavghosh06 I'd like to tack onto this issue, the user should be given the option to have sub-resources be suffixed with the environment name. When we briefly used multi-env (will pick it back up when it's ready for primetime!), the NONE env and a named environment that we copied from NONE resulted in sub-resources with identical names. So e.g. there's two AppSync endpoints with identical names corresponding to different multi-envs.

[kaustavghosh06]

@jkeys-ecg-nmsu I beleive that issue was fixed. Not the API names get suffixed with environment name (except the NONE envornment).

[jkeys-ecg-nmsu]

I haven't deleted the CF stack created by multi-env, so I didn't have insight into your latest patches.

Does your team plan to deprecate the single environment CLI when the multi-env is deemed stable?

[kaustavghosh06]

@jkeys-ecg-nmsu Yes, we're planning to do that soon.

[aaronbrighton]

I've also been running into what appears to be the issue described here. However, I'm not sure this is directly related to environment name duplication. Shouldn't the timestamp (20190103155640) in the hostingbucket name be regenerated for new environments preventing the environment name conflict?

We're resorting to resolving this by manually creating (using an updated timestamp) the "amplify/backend/hosting/S3AndCloudFront/parameters.json" when adding new environments and placing that file in the .gitignore to keep the environment specific data out of the repo.

A couple ideas for solving this (bug?):

• Can this S3 bucket name be moved into one of the environment specific property/tracking files instead of "amplify/backend/hosting/S3AndCloudFront/parameters.json"?
• At the moment deleting "amplify/backend/hosting/S3AndCloudFront/parameters.json" breaks "amplify push". Can "amplify push" regenerate the file if it's not found? This seems like the easiest fix, then we can simply add parameters.json to .gitignore.