vscode-remote-release
vscode-remote-release copied to clipboard
How can I call command in my extension?
commands.executeCommand('remote-containers.reopenInContainer', xxx);
commands.executeCommand('remote-containers.attachToRunningContainer', xxx);
Is it possible I can do this and what are the arguments types?
'remote-containers.reopenInContainer' does not have any arguments. 'remote-containers.attachToRunningContainer' takes a container id or name as an optional argument.
Many thanks @chrmarti , what about
commands.executeCommand('remote-containers.startAndOpenFolder', xxx);
commands.executeCommand('remote-containers.openFolder', xxx);
These commands are not stable API. What are you trying to do?
I want call devcontainers/cli to build dev container, then call commands.executeCommand('remote-containers.openFolder', xxx); to open the container.
It more like do the same thing reopen in container, but I want call it in my extension. and do some thing before/after the container opened, especially after that. If I call the reopen in container, vscode will reload, and I could not do any thing after that. so I want do these things by steps:
- do something.
- call
clito build container - open container folder (or just attach to container, but then I should open my working folder after that by hand)
- do something else.
You could add the following to your package.json to make sure your extension can run after the window reload:
"extensionKind": [
"ui"
],
You might have to add "*" to the activation events in the package.json to get it activated early on. (More specific activation events to avoid unnecessary activation are better performance-wise.)
Now I use pkg build cli into an executable app and in my extension i call it.
but even though I could not open remove folder. May I call commands.executeCommand('remote-containers.openFolder', xxx); ? what are the params?
I am failed with pkged cli on windows, macos too, only worked on linux. It seems node-pty is the issue I've got.
Is it possible to do this:
commands.executeCommand('remote-containers.rebuildContainer', myWorkspaceFolder);commands.executeCommand('remote-containers.startAndOpenFolder', containerID);
See https://github.com/devcontainers/cli/issues/498#issuecomment-1534409187 on node-pty. You would have to run pkg for each platform.
commands.executeCommand('remote-containers.openFolder', xxx); might be the easiest to make it work (needs a change on our side first).
commands.executeCommand('remote-containers.openFolder', xxx);might be the easiest to make it work (needs a change on our side first).
@chrmarti I have a similar problem and I would like to programmatically open a local folder in a devcontainer. If I use commands.executeCommand('remote-containers.openFolder', <folder-uri>); a new window is opened in the local filesystem, but not in the devcontainer (so, it seems to do the same as vscode.openFolder ?).
Would you know when you are planning to support opening a folder in a devcontainer using the remote contains API? I noticed similar issues related to the same in problem in the past:
- https://github.com/microsoft/vscode-remote-release/issues/336
- https://github.com/microsoft/vscode-remote-release/issues/473
- https://github.com/microsoft/vscode-remote-release/issues/6243
Thanks in advance!
@andpiccione If <folder-uri> is a local folder this should already work. I will fix the case where <folder-uri> is a folder on an SSH server when using Remote-SSH.
@andpiccione If
<folder-uri>is a local folder this should already work. I will fix the case where<folder-uri>is a folder on an SSH server when using Remote-SSH.
@chrmarti Maybe I'm doing something wrong, but it doesn't work as expected for me when <folder-uri> is a local folder.
To clarify, by running commands.executeCommand('remote-containers.openFolder', <folder-uri>); I would expect a new devcontainer (Docker container) to be created from the folder URI given.
However, the result of executing the command above is a new Visual Studio Code window with the folder referenced by <folder-uri> opened in the local filesystem (in my specific case, in WSL).
@chrmarti Any updates on the above? Thanks!
@chrmarti is out, I will reopen this just in case since it's not clear to me what's expected
I have a similar issue, I'm trying to connect to an existing remote tunnel from my extension. I already know that GitHub was used to create the tunnel and I know the tunnel id, because my extension initialised it.
Does executeCommand('remote-tunnels.connectCurrentWindowToTunnel') take any input args so that I can skip asking the user again for things I already know?
I have a similar issue, I'm trying to connect to an existing remote tunnel from my extension. I already know that GitHub was used to create the tunnel and I know the tunnel id, because my extension initialised it.
Does executeCommand('remote-tunnels.connectCurrentWindowToTunnel') take any input args so that I can skip asking the user again for things I already know?
@roblourens / @chrmarti any pointers would be greatly appreciated
@Simon-Count Could you open a issue for the tunnel case?
@andpiccione If
<folder-uri>is a local folder this should already work. I will fix the case where<folder-uri>is a folder on an SSH server when using Remote-SSH.@chrmarti Maybe I'm doing something wrong, but it doesn't work as expected for me when
<folder-uri>is a local folder.To clarify, by running
commands.executeCommand('remote-containers.openFolder', <folder-uri>);I would expect a new devcontainer (Docker container) to be created from the folder URI given.However, the result of executing the command above is a new Visual Studio Code window with the folder referenced by
<folder-uri>opened in the local filesystem (in my specific case, in WSL).
This works for me with a local folder:
await vscode.commands.executeCommand('remote-containers.openFolder', vscode.Uri.file('C:\\Users\\chrmarti\\devel\\test'));
And a WSL folder:
await vscode.commands.executeCommand('remote-containers.openFolder', vscode.Uri.file('\\\\wsl.localhost\\Ubuntu\\home\\chrmarti\\devel\\test'));
Closing again as fixed, let me know if this doesn't work.