Description
What problem would the feature you're requesting solve? Please describe.
A native Go worker process involves gRPC just like other language workers. Similar to DNI, it will need the path to the .exe. Execution is done via the shell (.\worker.exe)
Instead of making a new image for this, we can enable the Host to recognize this so that we can use generic containers. The Host should be able to communicate with the generated .exe using gRPC
Describe the solution you'd like
Although still in discussion, we can run the Host in custom mode but allow the gRPC service to start. This allows the Go process to communicate with the Host so that generic containers (ones that are not language-specific) find the exe and the Host starts it
Describe alternatives you've considered
Possibly use other existing language worker containers - but risky as they are already setup in a certain way. Go is closest to DNI in that both are compiled and output an assembly or executable. The Host will find the path using worker.config.json and execute accordingly:
Dotnet execution: dotnet.exe <path_to_dll>
Go execution: ./<path_to_exe>
Additional context
From "Using Available Dedicated Compute for Native Go Worker" post