I think this would definitely improve the UX. So the idea is that when we duplicate we prefill all parameters from the values of the original workspace but let the user overwrite any of them.

1. This doesn’t seem like a feature with the sole purpose of helping an enterprise manage scale, so it should be in community.
2. What if we made this a modification of the create flow instead of a new one? Then the CLI could have a --copy-params on coder create.

We should also be crystal clear that we're copying parameters. i.e., whatever cloud resource state the old workspace has isn't copied over, so the new workspace would have fresh storage volumes.

From looking at the frontend setup yesterday, it looks like modifying the existing flow would be one of the easier approaches for the UI, too

The page is already set up to intercept the website URL for default values, so the "duplicate workspace" button could basically be a link to the creation page, just loaded up with params from the previous workspace. The page could then have logic in place to detect whether this is a clone operation, and then display a warning message about what values actually get cloned

I think the word "Clone" should be avoided as it implies copying of the data within the workspace.

Going to be tapping @mtojek for the CLI portion, but from looking into how we have things set up so far, this is basically how I would imagine an implementation would work:

Basically, the solution would be following Ammar's suggestion by making this an extension of the existing coder create command. This would be implemented with the --copy-params flag, but just because this operation would likely be more uncommon, it probably doesn't make sense to also give it a shorthand flag, too.

Top-level idea

1. The coder create --help command would need to be updated to list the new option
2. coder create --copy-params would need to take the name of the workspace that the user wants to copy from. I couldn't find a good way to expose a workspace's ID through the CLI, so I'm going with the most identifying value that can be pulled from coder list
3. After using the command with the flag, the general flow for the CLI UI would be the same, including confirming with the user that they do want to make a new workspace. The confirmation graphic might need to be updated to list the name of the "source" workspace, though.
4. If the user accidentally lists a workspace that doesn't exist, list a friendly error message (possibly instructions for using the command)
5. It might be helpful to print a reminder when this command is used, being very clear that none of the state from an existing workspace will be copied over

Terminology

• Definitely agree with Steve that the CLI should make no use of the word "clone", just to make sure there aren't any mismatched expectations

Examples

# Copies the params from the existing coder/us-east-1 workspace. User would
# then go through the existing workflow for creating a user, such as being prompted
# for the name of the *new* workspace
coder create --copy-params coder/us-east-1

# Errors out because there isn't a CLI argument
coder create --copy-params

# --copy-params would need to be added to the output for this command
coder create --help

I mentioned this to Marcin already, but I'd be happy to update the website documentation for this, too.

I'm going with this issue.