Hi,
we are working on VS-code multicontainer project by support of the Torizon extension.
The env var DEBUG_SSH_PORT in section docker.environment inside the projectname.code-workspace file is set automatically to an empty string each time when choosing the Verdin devboard as default target in the Torizon extension,
Because of the precedence over the env vars used in a .vscode/tasks.json and .vscode/settings.json of each subfolder project, it is set for each debugging session to an an empty string.
For a running parallel debugging session with multi containers, each subfolder needs it’s indivdual setting for DEBUG_SSH_PORT in .vscode/settings.json.
I tried a lot of things to circumvent, but I can see no sense in a global forced setting which actually is individual to the subfolder container projects.
Is there an option to disable this function in the Torizon extension ?
Thanks and regards
Stephan
Greetings @millerfield,
We were able to reproduce a similar observation on our side as well. Could you try the following:
- Remove the
DEBUG_SSH_PORT* environment variables from your *code-workspace file
- Then in your individual projects when you set your default device it should set the debug port variables in each project’s
settings.json file.
- You may need to redo this every time you re-open the workspace since the extension may automatically re-add the port variables back to the
*code-workspace file.
Let us know if this works for you or not. For the time-being at least this needs to be manually overwritten like this. This issue is being reported to our team for future fixing/improvement.
Best Regards,
Jeremias
Hi jeremias.tx,
I am able to reproduce the steps you described.
Our team develops and debugs the individual projects by using the vs-code workspace.
So as far as I understand, there is almost no advantage of using the workspace in multi-container configuration.
In contrast, using the workspace in vs-code will break the debugging sessions until the .code-workspace file is edited after opening.
As solution, I need to tell my team to not use the workspace project anymore, instead opening each container project in a separate vs-code instance is the prefered way.
Hopefully this issue will be closed in the future, for now I think about using an older version of the Torizon extension.
Best regards
Stephan
Hopefully this issue will be closed in the future, for now I think about using an older version of the Torizon extension.
Understood. To be transparent with you, the multi-container functionally in our extension is experimental as you may already know. That is to say why it can seem not as polished as the rest of the features in our extension. That said, your feedback is helpful for us since it gives us information on how important the multi-container feature is for users like yourself.
Best Regards,
Jeremias
