I spent some time thinking about my proposal to support Go Actions, and I tried to address some weaknesses that emerged in the discussion (again, thank to James Thomas for pointing them out).
First, the most relevant, my approach requires you implement a supporting library able to run an http server in each language you want to support. So one for Swift, one for C/C++ (why not?), even one for Rust or D or Haskell or whatever. While it is relatively simple, it is definitely not a generic solution for supporting binaries. Second, there are some secondary problems: a “race condition”, when I upload an action, the current server will be closed so it won’t serve actions. For a very small amount of time, but it happens. Also I have some concerns about what happens if the user does not upload a proper executable. It could break the runtime, so some validation is needed. I hence decided to raise the bar and think to a better implementation. My updated proposal is now an extension of the current implementation, but using a pipe and keeping the "child" process running to serve actions, not terminate and be started again at each request. Instead of “exec” we should launch a process and pipe input, output and error. The process however should not be expected (as it is now in Docker actions) to read the standard input, write some logs then a serialised json objects and then terminate. Instead, the uploaded binary should be expected to: * read continuously the standard input line by line * interpret a single line as a serialised json object * write logs IN THE STANDARD ERROR * write the answer in the output as a single line In this way we can basically use all the compiled languages using just the standard libraries. It will behaves like a standard command line function. Well, almost (it still will have to encode and decode json). A controlling process (of course done in Go) will receive a “/run” request , then it will feed to the process, read his answer and then return the answer. The implementation is basically an extension of what I already coded in Go (no code to throw away). It is just a bit more difficult... How does this updated proposal sound like? -- Michele Sciabarra [email protected]
