Pie-in-the-sky idea: arbitrary automation scripts via docker image

Feature
1

Discourse Automation is really cool and useful, but the available automations are quite limited. Many of them seem like one-off hacks[1] meant to address some particular CDCK customer’s specific use case, rather than general-purpose tools.

It is possible to create custom automations, but there’s no way for hosted customers to drop those into place that I can see. Plus, they seem like they can be pretty dangerous. I’m sure I could work with the friendly Discourse staff to get an automation I’ve written deployed, but that seems like a lot of work on both sides.

So, here’s my idea:

  1. An admin interface[2] where one could provide links to OCI[3] images (using registry.example.org/imagename:tag).
  2. A way to associate an API key with that image (linked to existing API key admin page)
  3. A way to associate a webhook with that image (linked to existing webhook admin page)
  4. Either add a recurring-schedule option for this, or (better, I think!) add that to webhooks generically.

A broker/dispatcher would listen for the webhooks forward them to the matching container, providing the API key as a secret and the payload over either stdin or to an http port. (I’m imagining many of these would be “one shot” — the container would start, process one event, and exit — but there could be an option for persistent ones (or, perhaps, to listen for N seconds before exiting).

The containers would be run with reasonable resource limits, and either no persistent storage or access to the same storage pool attachments and stuff go in. For hosted sites, I can imagine automation CPU time as another per-plan limit alongside pageviews, emails, and storage.

The location of the site API could be provided either as an environment variable or another secret. Other network access would be forbidden by default, although it should be possible to allow specific outgoing connections.

One can, of course, set up such a thing right now “on the side”, but having it integrated with the API and Webhooks admin interfaces would be really slick (and basically entirely take care of the problem of managing secrets otherwise). Plus, the dispatcher/broker setup is a little complicated.

  1. I don’t mean that in a terrible sense ↩︎

  2. probably in the API section ↩︎

  3. “Docker” ↩︎

2 Likes
2

Also, this would have a “redeploy” button, and possibly an option to check for new container versions automatically on Discourse deploy or some other trigger.