Ensure GH CodeSpaces work

[0xTim]

We should ensure that the extension works when running in GitHub CodeSpaces and on vscode.dev. I'm pretty sure they should be fine as remote containers now work but we might need to provide some additional configuration or ensure a Dockerfile is set up correctly. Any required setup should go in the docs

[damuellen]

Unfortunately, the extension is a bit too eager, and wants to update the VSCode settings on every start of the codespace.

CodeLLDB requires the correct Swift version of LLDB for debugging. Do you want to set this up in your global settings or the workspace settings?

If you accept the following setting will be set "lldb.library": "/usr/lib/x86_64-linux-gnu/liblldb-6.0.so"

This path does not work for me, LLDB cannot be started.

The correct path is. "lldb.library": "/usr/lib/liblldb.so"

[adam-fowler]

Interesting the lldb library the extension wants to use is the library that the swift version of lldb reports it is using.

How are you setting up to run in Codespaces? I haven't looked into the Codespace stuff at all yet.

[damuellen]

I use a slightly modified version of devcontainer

[adam-fowler]

I use a slightly modified version of devcontainer

What version of the extension are you running? There was a fix in 0.1.1 related to remote containers and lldb.

[adam-fowler]

Also that devcontainer includes a different swift extension.

Have you tried a slightly simpler devcontainer.json

{
    "name": "Swift 5.5",
    "image": "swift:5.5",
    "extensions": [
      // vscode-lldb is automatically loaded as swift-lang is dependent on it
      "sswg.swift-lang",
    ],
    "settings": {
      // this setting stops the swift extension trying to set the linux lldb path in your workspace
      "lldb.library": "/usr/lib/liblldb.so"
    }
}

[damuellen]

This is my devcontainer.json

{ "name": "Swift", "build": { "dockerfile": "Dockerfile", "args": { "VARIANT": "latest", "INSTALL_NODE": "false", "NODE_VERSION": "lts/*" } }, "runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", "seccomp=unconfined" ], "settings": { "lldb.library": "/usr/lib/liblldb.so", "lldb.launch.expressions": "native", "lldb.evaluateForHovers": false, "terminal.integrated.scrollback": 50000, "terminal.integrated.defaultLocation": "editor", "sourcekit-lsp.toolchainPath": "/usr/bin/", "sourcekit-lsp.serverPath": "/usr/bin/sourcekit-lsp", "apple-swift-format.path": "/workspaces/swift-format/.build/release/swift-format", }, "extensions": [ //"pvasek.sourcekit-lsp--dev-unofficial", "sswg.swift-lang", "vadimcn.vscode-lldb", "hbenl.vscode-test-explorer", "makeitbetter.vscode-swift-test-adapter", "cweijan.vscode-office", "philhindle.errorlens", "wattenberger.footsteps" ], }

[damuellen]

I found the solution, the dockerfile from MS installs LLDB. Without it the extension does the right thing. Dockerfile

[adam-fowler]

I found the solution, the dockerfile from MS installs LLDB. Without it the extension does the right thing.

Dockerfile

Oh yeah I remember seeing that. I think at that point I decided I'd use my simple devcontainer from above. The MS version does all sorts of stuff that doesn't seem that necessary.

[damuellen]

I made a pull request at microsoft, so that no one else stumbles across this. https://github.com/microsoft/vscode-dev-containers/pull/1238

[adam-fowler]

Given vscode.dev and CodeSpaces are different things I think we should break this into two issues. I believe once microsoft/vscode-dev-containers#1238 is resolved we can do the same for CodeSpaces.

vscode.dev is a different thing and requires us supporting web extensions which severely limits what we can do.

[0xTim]

Ok I agree. I'll change this to Codespaces and create a separate issue for vscode.dev

[0xTim]

As an aside - does anyone have access to Codespaces? I didn't get on to the individual beta and none of the orgs I control has been given access to it yet

@damuellen do the new remote dev docs now work for a Codespace as well as regular remote dev running locally?

[damuellen]

In Codespace it works as it should, I have not tested another setup.