How do we add more transport mechanisms?

[hussainweb]

This is a support request.

I know a transport manager was added in #20 but I can't figure out a way to add more transports at runtime (per site). I was looking for something I could add with configuration on a per-site basis or by including a package in composer.json or by some other such mechanism. Something like "contrib modules".

I'm trying to add different ways to invoke drush in containers which are not docker-compose (or some other wrapper). For example, I want to add a site alias that runs drush in an OpenShift cluster for a specific project.

If adding a Transport in this project is the only way, how about adding a custom Transport that lets you wrap drush calls to a different command. So, drush @stage status could become oc rsh ... drush status. This would be very similar to the existing Docker Transport but would work for various wrappers such as oc, kubectl, or even ddev and lando.

I know there's a drush-alias setting but last I checked, there was a limitation that it only runs on a remote-host. That wouldn't make sense in these cases.

[hussainweb]

I forgot to mention that if the maintainers think a custom Transport is a reasonable way forward, I'm happy to help and create a PR to get things rolling.

[greg-1-anderson]

I don't think there's a way for Drush to register a transport from a hook, but I don't quite recall. There's definitely nothing in this project to discover and register transports automatically e.g. from the autoloader.

how about adding a custom Transport that lets you wrap drush calls to a different command.

This is essentially the purpose of a Transport. If you are envisioning a generic transport that is fully configurable from the fields in the alias record, that seems reasonable. It'd also be fine to submit individual transports for all of the systems mentioned above.

[greg-1-anderson]

Yeah, Drush just calls the static ProcessManager::addTransports(), and that's it.

The Drush redispatch hook is just an ordinary annotated command init hook, so you could write a command file with a pre-init hook that added more transports, and that should work. The command file would have to be in a global location, or perhaps in SITE/drush/Commands. A module commandfile definitely would not work, though.

[weitzman]

A PR adding this approach to the README would be appreciated.

[rudolfbyker]

kubectl transport support would be much appreciated. I am willing to try to write it if someone can point me to some docs or example code. But currently I'm clueless about where to start.

[greg-1-anderson]

A kubectl transport would be nearly identical to the SshTransport. Copy that class and adjust as needed. Search for all occurances of SshTransport in this library, and provide equivalent steps for the kube transport.

[rudolfbyker]

Awesome. Will put it on my TODO list. Will be able to take a look at this in February.

[hussainweb]

Ah, I completely forgot about this and was occasionally reminded I need this. :) Thanks, @rudolfbyker for picking this up. I'll see if I can do it in the coming week as this is something I want as well.

[hussainweb]

I looked into this and it was more challenging as I have lost the context I had then. @greg-1-anderson, can you share an example of working with the RedispatchHook. My search only turned up the documentation page (and the source) so I am not sure how to work with it.

Besides, I am thinking of extending the Consolidation\SiteProcess\Transport\SshTransport class to support a custom command prefix (is wrapper a better name?) That way, the site alias definition itself can specify the command to use. So, you could run platform ssh drush [command] instead of just ssh .... This might be good enough for even the original case of running it via oc rsh .... What do you think? It might look something like this:

# File: remote.site.yml
live:
  ssh:
    command: 'platform -e master ssh'

[rudolfbyker]

Working on kubectl transport now. It's working already :)

See draft PR #60

• Do I have to update the changelog, or do you? There was an instruction in the PR template to do that, but I'm not in control of version numbers, so that's a chicken-egg problem for me.
• How/where do we complain if a required argument in is not available in the site alias? https://github.com/consolidation/site-process/pull/60/files#diff-9013b283f310cfb112a3fb573207fcba0e92adf461281cb3d10d72b5989045bfR40
• I have not written tests yet. Coming up next …
• Do you have any comments on how the yaml structure under kubectl in the site alias should be designed?

[greg-1-anderson]

@hussainweb It sounds reasonable to add an attribute to the SshTransport class to specify a wrapper command to use in place of ssh

@rudolfbyker You could put "Unreleased" instead of a version number if you update the CHANGELOG. Changelog updates are appreciated, but I don't think anyone has done it before. Specific questions about your PR should be addressed on the PR itself.

[rudolfbyker]

Done. This is quite urgent for our workflow. Is there anything else I can do to help?

[hussainweb]

I have submitted a similar PR #61 for wrapping drush with any command. Since this is my first PR, it needs the maintainer's approval to run.

[rudolfbyker]

@greg-1-anderson will you please take a look at my PR #60 and let the workflow run so we can see if the tests pass?

[hussainweb]

FWIW, I got the tests to pass. I'm looking forward to the review now.