bitcrowd
Add a hostname in SSHKit.run's return tuple.
It would be nice to add a hostname in SSHKit's return tuple.
Currently SSHKit.run returns {:ok, output, exit_code}. https://hexdocs.pm/sshkit/SSHKit.SSH.html#run/3 This is not going to be easy to see its output without hostname when we run SSHKit.run with :parallel.
Something like {:ok, hostname, output, exit_code} will be very helpful.
Hi @seungjin,
if you have an SSHKit.Context struct context and the results of SSHKit.run/3, you could Enum.zip(context.hosts, results) together to tag each result with the corresponding host.
context = SSHKit.context(["h1.eg.io", …])
results = SSHKit.run(context, "…")
Enum.zip(context.hosts, results)
However, we've had a similar request before and I can see why this might be useful 🤔
If we decide to add this, I would probably add the SSHKit.Host struct, not just its name (maybe this is what you've had in mind anyway):
["h1.eg.io", "h2.eg.io"]
|> SSHKit.context()
|> SSHKit.run("echo \"Hello World!\"")
# => [
# {:ok, %SSHKit.host{name: "h1.eg.io", options: []}, [stdout: "Hello World!\n"], 0},
# {:ok, %SSHKit.host{name: "h2.eg.io", options: []}, […], 0},
# ]
What do you think? 🙂
Also I'd like to hear a few more voices @tessi, @brienw, @holetse 👋🙂
PS: This'd be a "breaking change" requiring a major version bump.
+1 from me on adding this support. I think this is something that we talked about changing in sshkit.ex last year some time when we were working on the output processing in Bootleg. I forget why we decided against it back then, but it would be great if the hostname (or some sort of identifier) was included in the output so we could explicitly know which host the output came from, instead of relying solely on the order of the elements in the output list. /cc-ing @rjanja for input as well, as he worked on the output logging/processing in Bootleg.
We achieved similar parallel-run output w/ host names by passing a channel function to SSH.run/3. This could certainly be made simpler by returning a host struct, alias or index with each message from SSHKit, but that would indeed be a breaking change. Maybe it'd be possible to add (and document) an optional host-associating channel function that could be used for this purpose in lieu of introducing a breaking change?
