Skip to content

Ensure GH CodeSpaces work #81

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
0xTim opened this issue Dec 24, 2021 · 13 comments · Fixed by #108
Closed

Ensure GH CodeSpaces work #81

0xTim opened this issue Dec 24, 2021 · 13 comments · Fixed by #108

Comments

@0xTim
Copy link
Member

0xTim commented Dec 24, 2021

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
Copy link

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
Copy link
Contributor

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
Copy link

I use a slightly modified version of devcontainer

@adam-fowler
Copy link
Contributor

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
Copy link
Contributor

adam-fowler commented Jan 5, 2022

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
Copy link

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
Copy link

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

@adam-fowler
Copy link
Contributor

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
Copy link

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

@adam-fowler
Copy link
Contributor

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
Copy link
Member Author

0xTim commented Jan 11, 2022

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

@0xTim 0xTim changed the title Ensure GH CodeSpaces and vscode.dev work Ensure GH CodeSpaces work Jan 11, 2022
@0xTim
Copy link
Member Author

0xTim commented Jan 11, 2022

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants