Various Executors for Different Jobs

[Southclaws]

Now that #27 is on the way, the concept of an Executor exists.

So far, the only executor is CommandExecutor and it just executes task.Target jobs. It's a bit misleading because the task.Target is structured to be a "command" anyway but... that's another issue.

It could make sense to introduce more executors that don't just run a command but may perform other tasks that are easier to declaratively set up via Pico configuration instead of creating a whole new git repo for it.

I'm thinking of webhooks as a first, maybe integrations like Slack or Discord.

More feature-creep, I know. But it could be useful.

A Docker-specific executor may be useful, as more granular information can be acquired via the Docker Go library.

Food for thought anyway...

[ADRFranklin]

I definitely like the idea of having multiple executors, so we can run multiple different tasks other then just executing the command.

I would prefer a Docker/Docker Compose executor, as this would make automation a little more interesting and simple, and this can tie nicely into a web ui, as it also allows you to get additional information about the repos that run them.

There should also be an API that can be accessed via unix sockets, or tcp etc, so that people could integrate their own stuff into it, too. Just something to interest people wanting to use pico, but might already have some system, and this would be useful for it to talk with. Some people have web services, or web ui themselves that might do some management, and it would be nice if it was easier for people to integrate this into it.

Social events like Discord/Slack using webhooks, and hopefully services like gotify would be a great addition to pico, this is already discussed in #9. It would be good to be able to setup on a per repo basis, which ones require events being sent. So lets take gotify for example, it would be nice if you could have a message list for pico itself, for health monitoring and logging, and for each repo to have it's own channel that it could be used for the logs that each of them make, or maybe configured for the executor directly, so logs can be closely be monitored.

I think it's a great way to go :)