Fix #989 vscode v1_92 breaking api change when spawning .bat or .cmd files

[Zoupers]

Follow https://code.visualstudio.com/updates/v1_92#_electron-30-update and https://nodejs.org/api/child_process.html#spawning-bat-and-cmd-files-on-windows

[chadlwilson]

Thanks! There are some test failures. (edit: fixed)

Do you know which vscode version this is compatible with? iIRC the tests run against the min version declared compatible at

gauge-vscode/package.json

Line 14 in 6a2f0cd

"vscode": "^1.71.0"

as well as the latest stable version.

Should be possible to gain confidence in both versions.

[chadlwilson]

I'm not an expert in the history of this project, however I don't quite understand why the master tests are passing on Windows right now, despite running against VSCode 1.92. I'd have thought they'd be failing, but perhaps it depends on how Gauge is installed :-/

https://github.com/getgauge/gauge-vscode/actions/runs/10244438966/job/28337428223

[Zoupers]

I think the reason might be that the gaugeCommand we searched in the test environment is not endswith .bat or .cmd.

[zabil]

@Zoupers can you sign you commits?

Refer https://github.com/getgauge/gauge-vscode/pull/990/checks?check_run_id=28337950758

[chadlwilson]

I'd prefer if were possible to get a failing test that is fixed by this, also to make sure we haven't regressed something else :(

The tests here with GHA use the gauge GitHub action to install gauge on windows but not sure how that is different to a regular gauge install for end users. Ideally it wouldn't be.

[zabil]

I'd prefer if were possible to get a failing test that is fixed by this,

VS Code recommends using insiders edition version for running the tests. I think that could be the best way.

[zabil]

But you did mention that it does not fail on 1.92 🤔 when technically it should. So maybe there's an issue with the test.

[chadlwilson]

Yes, that's kinda what I'm saying. So combining this change with the as-is tests creates the risk that it is also not exposing/validating properly something that might break on older VSCode versions which have older Node integrated.

[Zoupers]

@zabil @chadlwilson I have tested the reason I think it might be by this . It failed indeed.

[Zoupers]

The logic I modified is here.

        if (platform() === 'win32') {
            validExecExt = [".bat", ".cmd"]
        };

[chadlwilson]

The logic I modified is here.

        if (platform() === 'win32') {
            validExecExt = [".bat", ".cmd"]
        };

Ahh OK, thanks! So what I infer from this is that on GHA by defualt it is finding the .exe version that of course works fine as is not a shell command. The current ordering is a bit weird to me, it should probably be exe > cmd > bat in a general sense, but not the major issue here.

This probably varies based on whether you install via installer vs npm vs zip file vs build-from-source. The github action tests here build gauge:master from source (i.e dont use a released version) and that means only the exe will be available - so it works.

Bit confused about which install mechanism will end up relying on a .bat or .cmd though, as I thought all versions were distributed as a basic executable now. Knowing this would probably allow us to validate this reliably?

@Zoupers how did you install Gauge? Which version?

[Zoupers]

@chadlwilson I install gauge via npm.

Gauge version: 1.5.6
Commit Hash: a5e7eb63

[chadlwilson]

@chadlwilson I install gauge via npm.

Gauge version: 1.5.6
Commit Hash: a5e7eb63

Does it still fail on the current/latest version from npm? (Probably does, but worth a go)

[Zoupers]

@chadlwilson I install gauge via npm.

Gauge version: 1.5.6
Commit Hash: a5e7eb63

Does it still fail on the current/latest version from npm? (Probably does, but worth a go)

Yes, I tried this, still fail.

Gauge version: 1.6.7
Commit Hash: 684d870

[chadlwilson]

Ok thx. I'll play with the tests to double check if we can catch this differently.

[chadlwilson]

I didn't merge this earlier as I was uncomfortable about lack of regression for the failure itself, or older versions and my Windows VM wasn't in the right state to test. And then I forgot about it 😅

I thought it could be a bit simpler with less duplication too but wanted to check it didn't regress anything for older VSCode versions first.

[Zoupers]

So we should add a new regression test ci process that could be manually run?
According to this, we already have the capability to do the regression test, but there is no ci process that using different way to install gauge.

[chadlwilson]

So we should add a new regression test ci process that could be manually run?

No, nothing manual.

The core capability that IMHO should be automatically tested, is ability to spawn both shell and direct exec processes from Windows based on the priority order in the code, with ability to run the same tests for regression across platforms and supported VSCode versions. (which the GHA workflows already handle)

According to this, we already have the capability to do the regression test, but there is no ci process that using different way to install gauge.

A test doesn't specifically need to launch the Gauge process, as suggested at #1049 (comment) It doesn't need to be a full "integration test with a real gauge installation" to be a useful test for the underlying process spawning logic; but we might need to refactor out all the copy+pasted code here to make it more testable, since it has gotten increasingly complicated - and perhaps allow it to spawn a dummy gauge.bat, gauge.cmd or similar created specifically for the test. That was my plan anyway, although I haven't looked into how possible that is, and the best way to achieve it with the current test setup.

[Zoupers]

Ok, I might have got your idea. The thing that we should do is to test the command invoke ability, so we could have all the scripts form that we might invoke to test.