Updatecli focus on dependencies which can't be easily identified based on the context.
Hence the need to describe how to retrieve an information and then what to do after with it.
And then once you have the latest version, you also have the challenge to know how to apply that update.
More I dig in the dependency management topic, more I realize that we still have long way to go.
> 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...
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.
Kind of, the reason why it's a bit difficult to describe the project is because the different component mean different things to different people.
I built updatecli so I could use it to help me maintain infrastructure as code, then bit by bit, I discovered how other people were using it to solve challenges that I didn't imagine.
We monitor the latest Certmanager chart version available and we bump our git repository so Helmfile can pick the latest version and update our Kubernetes clusters.
The purpose is to automate infrastructure as code.
Thank you for the feedback.
So If I understand you correctly, you suggest to improve the feedback loop when writing updatecli configuration from an IDE.
I worked for 5 years at CloudBees within the community team so maintaining the infrastructure project was one the things I worked on https://GitHub.com/jenkins-infra
To add on top this. I started by supporting other DSL such as Json. Then I realized it was adding burden on me in terms of documentation since people would ask me for different examples.
You need very good tests in place to automatically change something or a lot of trust in your dependencies :P.
It's not the case on most of my project, so I never commit directly to the main branch, instead I commit on a temporary branch then open a PR on GitHub so we just review and merge the changes.
Thank you very much.
Major difference with dependabot is that you can use it for more use cases as you define what, how, and when something should be updated
It's Kubernetes in Kubernetes and a reference in k3s which is also a project we are heavily contributing to, at SUSE.