I like the idea of automatic proposed changes triggered by external events, but I'm not sure a monolithic tool with plugins is the best way of going about it. The Unix way to solve this problem would be to decompose your program into a couple of different programs that just do one thing, with flexible inputs and outputs.
"Sources": what does this do? Collect information. This doesn't need to be a particular program, this could just be a data specification that any program could generate data according to the spec. Thus you could have a dozen different programs that could each generate the spec.
"Conditions": This also doesn't need to be a dedicated program. Any program that can read the data specification can have one or two lines of simple logic; a couple lines of shell script would work fine. For complicated conditions you could use a more complex language, or build applications with specific features that are needed often.
"Targets": This part seems a little complicated, could use deconstructing a bit more. If you want to modify a YAML file, that is one dedicated kind of action to take. If you want to commit that file to a Git repo, that's another action. Opening a PR is another action (PRs aren't a Git primitive). Those three things could be separated but run one after another, all as separate programs.
The plugin aspect is certainly useful for being able to share pre-made solutions. But those "plugins" don't need to be strongly coupled to a monolithic application. Drone.io is a fantastic example of a loosely-coupled cloud-native design; every plugin is actually a Docker container, which is just an abstraction around arbitrary applications that uses environment variables and command-line options. (Also, the data specs absolutely needs a version number, and should consider backwards compatibility)
"Sources": what does this do? Collect information. This doesn't need to be a particular program, this could just be a data specification that any program could generate data according to the spec. Thus you could have a dozen different programs that could each generate the spec.
"Conditions": This also doesn't need to be a dedicated program. Any program that can read the data specification can have one or two lines of simple logic; a couple lines of shell script would work fine. For complicated conditions you could use a more complex language, or build applications with specific features that are needed often.
"Targets": This part seems a little complicated, could use deconstructing a bit more. If you want to modify a YAML file, that is one dedicated kind of action to take. If you want to commit that file to a Git repo, that's another action. Opening a PR is another action (PRs aren't a Git primitive). Those three things could be separated but run one after another, all as separate programs.
The plugin aspect is certainly useful for being able to share pre-made solutions. But those "plugins" don't need to be strongly coupled to a monolithic application. Drone.io is a fantastic example of a loosely-coupled cloud-native design; every plugin is actually a Docker container, which is just an abstraction around arbitrary applications that uses environment variables and command-line options. (Also, the data specs absolutely needs a version number, and should consider backwards compatibility)