Today, people can't run copilot [env/svc] init --name abc twice - the second execution will return an error [env/svc] "abc" already exists. This is to remind users that "abc" might have been managed by another workspace, and it is not recommended to manage the same env/svc via. 2+ different workspace.
However, Copilot don't have to error out if "abc" is managed by the current workspace. i.e. a succeed execution of svc init won't result in multiple workspaces managing the same env/svc.
In this case, Copilot should:
- Skip updating stack set.
- Skip the manifest creation.
- Not error out.
One benefit that this brings is that - new users that are just trying out copilot init sometimes have to exit in the middle of the program to tweak/understand the manifest. However, once they exit init, they wouldn't be able to run it again because of the said error. This allows them to do that, and provides a better onboarding experience.
Today, people can't run
copilot [env/svc] init --name abctwice - the second execution will return an error[env/svc] "abc" already exists. This is to remind users that "abc" might have been managed by another workspace, and it is not recommended to manage the same env/svc via. 2+ different workspace.However, Copilot don't have to error out if "abc" is managed by the current workspace. i.e. a succeed execution of
svc initwon't result in multiple workspaces managing the same env/svc.In this case, Copilot should:
One benefit that this brings is that - new users that are just trying out
copilot initsometimes have to exit in the middle of the program to tweak/understand the manifest. However, once they exitinit, they wouldn't be able to run it again because of the said error. This allows them to do that, and provides a better onboarding experience.