- Apply the name/tunnel-name from the CLI to automatically
(do a normal tag sync). Previously the CLI could host tunnels that
were unusable unless the consumer did the tag setup, which they
should not.
- Allow "tunnel ID" to be specified in the new `<id>.<cluster>` format
that devtunnels has adopted.
- When turning on remote tunnel access, a quickpick is now shown asking
users whether it should be installed as a service or just run in
the session.
- Picking the service install will install the tunnel as a service on
the machine, and start it.
- Turning off remote tunnel access will uninstall the service only if
we were the ones to install it.
- This involved some refactoring to add extra state to the RemoteTunnelService.
There's now a "mode" that includes the previous "session" and reflects
the desired end state.
- I also did a cleanup with a `StreamSplitter` to ensure output of the
CLI gets read line-by-line. This was depended upon by the remote tunnel
service code, but it's not actually guaranteed.
- Changes in the CLI: allow setting the tunnel name while installing the
service, and make both service un/installation and renames idempotent.
Closes https://github.com/microsoft/vscode/issues/184663
Other connected clients will now print:
```
Connected to an existing tunnel process running on this machine. You can press:
- Ctrl+C to detach
- "x" to stop the tunnel and exit
- "r" to restart the tunnel
```
These are then sent to the server to have that take effect. This is
mostly some refactors in the singleton_server to make the lifecycle work.
Fixes#167708 by using a more predictable naming scheme.
```
me> Write a haiku about the extinction of birds
chatgpt>
Silent skies above,
Once lively songs now gone,
Fading memories.
```
Fixes https://github.com/microsoft/vscode/issues/167760
The VS Code CLI gets run from a bash/shell script. This prevents interactions--in the former case, it doesn't look like a tty, and in the latter case batch scripts don't seem to support having interactive subprocesses.
This PR avoids interactions if stdin is not a tty, prompting the user to use the flag instead. Use of the flag is also persisted like an interactive agreement prompt.
This uses a hash of the tunnel ID to create the connection token, which
should be sufficient to resolve the issues.
We also now publish the protocol version in the tunnel tags, since the
connection token must be supplied in the resolver, which is before we
start connecting to the tunnel.
See https://github.com/microsoft/vscode-internalbacklog/issues/3287
Fixes https://github.com/microsoft/vscode-cli/issues/563
If a new tunnel `--name` was provided but the existing tunnel was deleted,
the CLI would error out with a lookup failed message. Instead it now
recreates it like it normally would.
