You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'm currently invoking noxious-server via std::process::Command in a Rust module in my CI. This mostly works great!
I did have some issues though when debugging timing of the process coming up and successfully binding to a port, then also ensuring it is reliably killed.
Describe the solution you'd like
It might be nice to make the noxious-server package both a library and a binary, where the binary is a thin wrapper. I'm thinking that in CI, I'd have a choice to something something tokio::spawn(noxious_server.serve(...))
Describe alternatives you've considered
This isn't strictly required, and it does increase API surface of the package.
The text was updated successfully, but these errors were encountered:
Yup, core has the server. What it doesn't have is the REST API and the store that keeps the proxies. I can definitely see the benefit of exposing the server as a library as well though.
Is your feature request related to a problem? Please describe.
I'm currently invoking
noxious-server
viastd::process::Command
in a Rust module in my CI. This mostly works great!I did have some issues though when debugging timing of the process coming up and successfully binding to a port, then also ensuring it is reliably killed.
Describe the solution you'd like
It might be nice to make the
noxious-server
package both a library and a binary, where the binary is a thin wrapper. I'm thinking that in CI, I'd have a choice to something somethingtokio::spawn(noxious_server.serve(...))
Describe alternatives you've considered
This isn't strictly required, and it does increase API surface of the package.
The text was updated successfully, but these errors were encountered: