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

ENV Vars set in vscode-test.js do not persist in Debug Mode (but do in Run mode and vscode-test command line) #17

Open
JustinGrote opened this issue Jan 5, 2024 · 4 comments
Labels
info-needed Issue requires more information from poster

Comments

@JustinGrote
Copy link

JustinGrote commented Jan 5, 2024

// .vscode-test.js
const { defineConfig } = require('@vscode/test-cli')

module.exports = defineConfig({
	files: 'test/test.ts',
	launchArgs: ['--profile=vscode-pester-test'],
	env: {
		TEST: 'kaboom'
	},
	mocha: {
		ui: 'bdd',
		preload: ['@swc-node/register'] // enable-source-maps option does not seem to work with VSCode executable
	}
})

With Debug:

 ✓ test
Test Setting undefined

With Run/vscode-test

 ✓ test
Test Setting kaboom

Workaround

Setting the values in extension-test-runner.DebugOptions env property seems to work

@connor4312
Copy link
Member

This seems to work for me now -- are you still hitting issues?

image

@connor4312 connor4312 added the info-needed Issue requires more information from poster label Jul 5, 2024
@eliericha
Copy link
Contributor

Hello,

I'm hitting an issue related to this and running tests in a remote setup.

I have the following in my .vscode-test.mjs:

dotenvExpand.expand(dotenv.config({ override: true }));

I am connected to a remote workspace over SSH.

My test consists of running a task through vscode.tasks.executeTask. The task has a ShellExecution, i.e. it runs a command in a shell which calls a tool on PATH.

When running the test in normal mode, it works. The environment is passed to the test, and to the underlying ShellExecution correctly.

When running in debug mode, I see something weird. The task fails to find the tool on PATH, i.e. the environment was not passed onto the terminal. However the node process has the correct environment because if I use the debug console to inspect process.env.PATH, it does include the right path.

Do you have an idea why the environment is not being passed to the ShellExecution ?

Thanks

@eliericha
Copy link
Contributor

Actually I created a reproducer of the issue that does not involve dotenv, and doesn't involve a remote setup.

I created a project test-env in my fork of the extension samples repository.

I wrote two extension tests here. One that checks the value of the SOME_VAR environment value directly in process.env, and another one that executes a ShellExecution task that also checks the same env variable.

I observe the following:

  1. Setting the env var in process.env in .vscode-test.mjs only impacts non-debug executions (The Test: Run All Tests command).
  2. In non-debug executions both tests pass as exepected, i.e. the env var is available in process.env and is inherited by tasks.
  3. To set the env var for debug executions (The Test: Debug All Tests command), I have to set the env property of the test configuration or the extension-test-runner.debugOptions.env workspace setting.
  4. But nonetheless, in debug executions the first test passes and the second one fails. I.e. the env var is available in process.env but is not inherited by tasks.
  5. This reproduces in a local workspace. No remote setup involved.

Any idea why that happens?

Is there a way to set environment variables for debug executions that would behave like non-debug executions? I.e. I want tasks invoked in testing to inherit the environment.

Do I need to open a separate issue for this?

Thanks!

@eliericha
Copy link
Contributor

Coming back to this, I suspect that ShellExecution and ProcessExecution cache process.env before the env and envFile properties of a debug configuration are applied.

Thus, when debugging, process.env has the environment coming from the debug configuration, but tasks executed through ShellExecution and ProcessExecution do not have that environment.

I created an issue in the main project for this, with a link to my reproducer. I hope it will be considered.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
info-needed Issue requires more information from poster
Projects
None yet
Development

No branches or pull requests

3 participants