search

dispatchrun / dispatch

Entrypoint of the Dispatch ecosystem.
11 stars 1 forks source link

Fix Windows build and build on Windows CI #74

Closed chicoxyzzy closed 4 months ago

chicoxyzzy commented 4 months ago

We should use something platform-independent instead of printenv. I'm going to work on this in another PR

Tyl13 commented 4 months ago

Could a way of checking the environment variables independently of the operating system be by introducing either a flag or command to return the environment variables that the CLI has access to?

This means you don't have to worry about if Microsoft changes their commands, and guarantees that the environment variables returned are the same ones that the command actually has access to. A flag would allow it to be used with any of the commands so that you can still test the run command.

chicoxyzzy commented 4 months ago

Could a way of checking the environment variables independently of the operating system be by introducing either a flag or command to return the environment variables that the CLI has access to?

This means you don't have to worry about if Microsoft changes their commands, and guarantees that the environment variables returned are the same ones that the command actually has access to. A flag would allow it to be used with any of the commands so that you can still test the run command.

Yes, I was thinking about that. For now I'm going to disable these tests on Windows and work on enabling them in a next PR

chicoxyzzy commented 4 months ago

@chriso please let me know if I should do something to kill all the processes on Windows similar to how it's done for linux and darwin.

@achille-roussel not sure how to use run_unix.go, it says

killProcess redeclared in this block (see details) [windows]

...so I reuse the same code in run_linux.go and run_darwin.go here

chriso commented 4 months ago

The reason we use the lower level syscall.Kill for Linux/macOS is because it lets us pass a negative PID, which sends the signals to all processes in the process group we create (via SysProcAttr.Setpgid) when spawning the local application.

The higher level cmd.Process.Kill() is equivalent to syscall.Kill(cmd.Process.Pid, syscall.SIGKILL) on these platforms, which sends the signal to the process rather than the process group.

I'm not familiar with Windows syscalls so I'm not sure how to accomplish the same thing there. Windows may not even have the concept of process groups. I think what you've done here – default to using cmd.Process.Kill() – is the right approach for now :+1: We can figure out a better strategy for Windows later if/when necessary.