[throwaway984393]

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)

[olblak]

> 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.

Waow, thanks a lot for you feedback, especially to take the time to write this down. I'll do my best to answer as you cover different topics which have been scratching my head since the beginning of the project. But first keep in mind that I had a strong constrain which was my spare time :).

It's definitely something which I am planning to improve.

Currently everything is done at build time and rely on Golang interface. So a resource kind need to match a golang package. A package needs to implement the correct function for it to work. for example for a "source" you need to implement the "source" function as in the following example.

``` func (m *Maven) Source(workingDir string) (string, error) { // Implement whatever you need and return the source value return "the source value", "an error if needed" } ``` Like in this package https://github.com/updatecli/updatecli/tree/main/pkg/plugins...

And the matching between a package and a resource kind is done here https://github.com/updatecli/updatecli/blob/main/pkg/core/pi...

Ideally I would like it to be done at runtime similar to Terraform.

If needed you can still use the "shell" target but then you put a strong dependency on the tool used within your script. Let say that your script call a python tool, then you need to be sure that both your local and ci environment have the same python version. I personally consider it as a fallback when I don't have the time to implement something better.

Ideally I would like to be able to use resources which are very specific to environment and therefor not suitable for everybody.