cc @bpmct

We should not add multiple top-level commands for this bespoke feature. It will bloat the help.

Good call, fixed.

For more context on extensions, since you can be connected to any workspace on any deployment at any time, and the connections are essentially stored as host names, it means we need them all in the SSH config at once and not just the last configured workspace like the Coder CLI currently does. So in the JetBrains plugin we have blocks like this:

Host coder-jetbrains--workspace.agent--company.com
  ProxyCommand ... --global-config ~/.config/coder-gateway/company.com ...

When you connect, it stores coder-jetbrains--workspace.agent--company.com in the list of recent connections.

(One issue with company.com at the end is that it can unexpectedly collide with *.company.com blocks which are probably not uncommon, so it might be better to have it up front, although that could also be considered a feature.)

But, this becomes tricky if we want to support the shorter ssh coder.<workspace>.<agent?> syntax.

Maybe we just output both?

# Deployment-specific syntax, this gets added/updated every time you run config-ssh with the matching deployment active
Host coder--company.com--workspace.agent
  ProxyCommand ... --global-config ~/.config/coder/company.com ...

# Shorter syntax, this gets replaced every time you run config-ssh with any deployment active
Host coder.workspace.agent
  ProxyCommand ... --global-config ~/.config/coder/current ...

And the shorter ssh workpace.agent syntax will only work for the most recent context, while the plugins can use the longer syntax that does not depend on whatever the current context happens to be.

Maybe we use a Host coder.* syntax and parse out the workspace details in the CLI (similar to have vscodessh works). If we did that then we could just output the one block, and then figure out in the CLI how to connect based on the host name. (ssh coder.workspace uses the current deployment, ssh coder.workspace--dev.coder.com uses dev.coder.com, something like this).

But there could be a smarter way of doing all this. 🤔

Edit: I wish we could just have separate SSH configs for each deployment but in JetBrains at least there does not seem to be any way to configure the SSH config file path.

We have written a wrapper around coder CLI. This helper handles the context switching for us. It is a TUI with most common functions...

That screenshot provides some great context, thanks @MrPeacockNLB.

@code-asher I think I see how just storing deployment URL+session_token doesn't really help with the ssh config resolution.

So I'm understanding correctly, if I use Gateway to access workspaces on two different coder deployments, are all my workspaces visible in the extension at all times? I think it would be ideal if that were the case for both extensions. Meanwhile ssh <workspace>.<agent> points to the current deployment.

If we put both the verbose and implicit hosts in in the ssh config, could we support the above behavior?

The screenshot above shows something else I didn't consider which is copying the binary. IE I have a mainline (staging) and stable (production) deployments and need the version to switch.

What do we think about

coderv2/
- current/ # symlinks to current deployment
- dev.coder.com/
  - session 
  - url
  - binary
- alt.coder.com/
  - session
  - url
  - binary

We could also define these in a deployments.yaml.

if I use Gateway to access workspaces on two different coder deployments, are all my workspaces visible in the extension at all times?

From the "Connect to Coder" button, only the workspaces from the current deployment are visible. From the "Recent Projects" screen (from the sidebar) all projects that have been connected to in the past are visible, from any deployment.

But, there is no place currently that shows all workspaces for all deployments, although we could add this. The multiple deployment thing at the moment really only exists to support reopening previous workspaces that might belong to a different deployment than the current one.

If we put both the verbose and implicit hosts in in the ssh config, could we support the above behavior?

Yup I think so.

What do we think about

I like this, this is pretty much what the JetBrains plugin does, minus the symlink. A directory for each deployment with the config and binary for that deployment.

@code-asher, is this still in your backlog? We may postpone it until we can consider the organization context in the CLI.

No, it is not in my backlog at the moment. Still interested in implementing though once the dust settles.

closing in favor #9857.