task
task copied to clipboard
Add remote execution via SSH?
Would this really add value?
I'm trying to review the issues and maybe make some pull requests. This is a task runner and not a Fabric script/remote execution tool. So would this not add extra complexity that is not needed when we can just use the ssh command in a task when it is needed?
From the docs:
Task is a task runner / build tool that aims to be simpler and easier to use than, for example, GNU Make.
I started a discussion before I found this issue but I created a proof-of-concept of this (naive implementation). But before I worked on it any more I did want to find out what upstream thought about the idea. Thanks!
Related project that might give some ideas: https://github.com/prologic/shops
What would the benefits be compared to just running ssh -t user@host "ls -la" as a command?
One thought was to integrate it better into the experience of running tasks remotely so they felt like running tasks locally. Of course you can do what you suggest and several other things to accomplish that.
For that matter Taskfiles can be done with Makefiles. :)
Hi @futuretim, I found work you mentioned here: https://github.com/futuretim/task/tree/remote_servers
I would say that this idea of running tasks remotely has very low priority at the moment. This issue is open so we have some discussion on how that would work if it eventually happen.
@futuretim That would have been a better idea in stead of tinkering with it to try and see if it fits without asking, like i did
I think this issue can be closed now that we have the Remote Taskfiles experiment. Work on this is far from complete, but progress can be tracked in #1317.
@pd93 This issue is a different proposal, though. The idea here is that the commands listed on cmds: are executed remotely in another machine using SSH. It's similar to the proposal to execute the commands inside a Docker machine.
Ah ok. I misunderstood the intention of the issue. This reminds me of https://github.com/go-task/task/issues/448#issuecomment-1665849225. I feel like it might fit better under that issue instead?
Good point. Closing in favor of #448.