Skip to content
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

refactor(amazonq): Improve robustness of lsp installation process #6364

Merged
merged 2 commits into from
Jan 15, 2025

Conversation

jpinkney-aws
Copy link
Contributor

Problem

  • resolvers should produce runable binaries with the correct permissions
  • nodepaths should correctly target the correct os
  • workspace context lsp should reference the correct location

Solution

  • resolvers now produce runable binaries
  • nodepaths are now correct for the workspace context lsp on windows/mac/linux
  • lsp location is now correct for the workspace context lsp

  • Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
  • Your code changes must meet the guidelines in CONTRIBUTING.md.
  • License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

@jpinkney-aws jpinkney-aws requested review from a team as code owners January 14, 2025 18:44
Copy link

  • This pull request modifies code in src/* but no tests were added/updated.
    • Confirm whether tests should be added or ensure the PR description explains why tests are not required.

@jpinkney-aws
Copy link
Contributor Author

/runIntegrationTests

// If the extension is launch in debug mode the debug server options are use
// Otherwise the run options are used
let serverOptions: ServerOptions = {
run: { module: serverPath, transport: TransportKind.ipc },
debug: { module: serverPath, transport: TransportKind.ipc, options: debugOptions },
}

const child = cp.spawn('node', [serverPath, ...debugOptions.execArgv])
const child = cp.spawn(executablePaths.node, [serverPath, ...debugOptions.execArgv])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we can find a way to use our ChildProcess module, then after #6304 we get instrumentation for free :)

@@ -22,7 +25,21 @@ export class WorkspaceLSPResolver implements LspResolver {
new Range(supportedLspServerVersions)
).resolve()

const nodeName =
process.platform === 'win32' ? getNodeExecutableName() : `node-${process.platform}-${process.arch}`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would the node-platfor-arch logic fit into getNodeExecutableName ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason this idea only exists for the workspace installer. I think the actual standard (which the actual codewhisperer language server uses) is just node.exe/node

@jpinkney-aws jpinkney-aws merged commit 206b8a5 into aws:feature/amazonqLSP Jan 15, 2025
11 of 17 checks passed
@jpinkney-aws jpinkney-aws deleted the improve-detection branch January 15, 2025 14:05
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 this pull request may close these issues.

3 participants